[squid-users] squid workers question

[Eliezer Croitoru]

Just to add that one of my current test labs of squid is a combination of:
1 haproxy as balancer(or a custom LB I wrote)
2+ squid instances with the proxy protocol enabled and each has it's own ufs\aufs cache_dir

The idea was to verify if it would be possible to let different instances communicate via htcp\icp as the "signaling" or "communication" channel instead of shared memory.
The situation is that I cannot continue testing it since there is a bug with the sibling proxies communication.

I would be happy if this is will be resolved and then the test might be able to let couple squid instances that runs on the same machine to be able to utilize aufs\ufs better(taking into account that there is an overhead to this whole setup..) for some places.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer at ngtech.co.il


-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Amos Jeffries
Sent: Thursday, March 9, 2017 6:36 PM
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] squid workers question

On 10/03/2017 5:19 a.m., Matus UHLAR - fantomas wrote:
>> On 03/09/2017 07:21 AM, Matus UHLAR - fantomas wrote:
>>> I have installed squid 3.4.8 on linux 3.16/64bit (debian 8 / jessie
>>> version)
>>>
>>> (I know it's old, but I prefer using distribution-provided SW unless 
>>> it has real problem distribution isn't able to fix)
> 
> On 09.03.17 09:07, Alex Rousskov wrote:
>> My answers are based on v5 code. (I know v5 is new, but I do not 
>> remember v3.4 specifics and v5 answers will be valid for a longer 
>> time.)
> 
> OK
> 
>>> I configured rock store (for smaller files) and (later) standard 
>>> aufs for others:
>>>
>>> cache_dir rock /var/spool/squid3/rock 1024 max-size=32768 #cache_dir 
>>> aufs /var/spool/squid3 8192 16 256 min-size=32769
>>>
>>> are those correct values? (bug 3411 says something about 256B 
>>> metadata)
> 
>> Both rock and AUFS stores support large objects so there is no 
>> requirement to split storage based on object sizes. Each store has 
>> various pros and cons, but lack of large object support is not one of 
>> the distinguishing characteristics.
> 
> I thought the cons of *ufs/disks is ineffective storage of small 
> files, while rock is ineffective with big files...
> 

Yes, *efficiency*, not lack of support.

[except in this case of your 3.4 where rock does explicitly lack the support].


>>> - do I get it right that kid1 is the Master, kid2 is the disker for rock
>>>   store and kid3 is the single worker process?
>>
>> In SMP mode (which, BTW, AUFS store does not support),
> 
> could it crash squid instead of complaining?

Are you talking about when AUFS is used in SMP mode? it is not that simple, there are ways to configure it to be used by a single worker ("if" directive, or $(process_number) macro) which is fine and work well for certain version-specific situations.


Amos

_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users