[squid-users] Squid multithread

Yuri Voinov yvoinov at gmail.com
Mon Nov 14 17:09:30 UTC 2016 


14.11.2016 21:59, Eduardo Carneiro пишет:
> Yuri Voinov wrote
>> http://wiki.squid-cache.org/Features/SmpScale
>>
>> http://wiki.squid-cache.org/MultipleInstances
>>
>>
>> 14.11.2016 20:22, Eduardo Carneiro пишет:
>>> Hi everyone!
>>>
>>> I have a Squid 3.5.19 with dynamic content cache using url rewrite. It's
>>> a
>>> virtual machine (VMWare) with 2 quad-core processors each. Squid proccess
>>> is
>>> 100% in one of my eight cores and the access it's getting very slow.
>>>
>>> There exists any way to compile squid with multithread option? The idea
>>> is
>>> spread this processing beetwen the 8 cores.
>>>
>>> Thanks.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-multithread-tp4680488.html
>>> Sent from the Squid - Users mailing list archive at Nabble.com.
>>> _______________________________________________
>>> squid-users mailing list
>>>
>> squid-users at .squid-cache
>>> http://lists.squid-cache.org/listinfo/squid-users
>> -- 
>> Cats - delicious. You just do not know how to cook them.
>>
>> _______________________________________________
>> squid-users mailing list
>> squid-users at .squid-cache
>> http://lists.squid-cache.org/listinfo/squid-users
>>
>>
>> 0x613DEC46.asc (2K)
>> <http://squid-web-proxy-cache.1019090.n4.nabble.com/attachment/4680489/0/0x613DEC46.asc>
>> signature.asc (484 bytes)
>> <http://squid-web-proxy-cache.1019090.n4.nabble.com/attachment/4680489/1/signature.asc>
> From what I understood I will need to use each instance in different ports,
> right? This does not solve my problem. There are any way to separate one
> instance for accesses and another for cache?


      What can workers share?

Using Coordinator and common configuration files, Squid workers can
receive identical configuration information and synchronize some of
their activities. By default, Squid workers share the following: 

  * Squid executable, 
  * general configuration, 
  * listening ports (but shared ICP and HTCP ports do not work well; see
    below), 
  * logs, 
  * memory object cache (in most environments), 
  * disk object cache (with Rock Store only), 
  *

    insecure cache manager statistics (detailed elsewhere
    <http://wiki.squid-cache.org/Features/CacheManager#SMP_considerations>), 

  * SNMP statistics.

Cache indexes are shared without copying. Other shared information is
usually small in terms of RAM use and is essentially copied to avoid
locking and associated performance overheads. 

Conditional configuration and worker-dependent macros can be used to
limit sharing. For example, each worker can be given a dedicated
http_port to listen on. 

Currently, Squid workers do not share and do not synchronize other
resources and services, including (but not limited to): 

  * memory object cache (in some environments), 
  * disk object cache (except for Rock Store), 
  * DNS caches (ipcache and fqdncache), 
  * helper processes and daemons, 
  *

    stateful HTTP authentication (e.g., digest authentication; see
    bug 3517 <http://bugs.squid-cache.org/show_bug.cgi?id=3517>), 

  * delay pools, 
  * SSL session cache (there is an active project to allow session
    sharing among workers), 
  *

    secure cache manager statistics (detailed elsewhere
    <http://wiki.squid-cache.org/Features/CacheManager#SMP_considerations>), 

  *

    ICP/HTCP (works with a caveat: If multiple workers share the same
    ICP/HTCP port, an ICP/HTCP response may not go the worker that sent
    the request, causing timeouts at the requesting worker; use a
    dedicated ICP/HTCP port as a workaround
    <http://www.squid-cache.org/mail-archive/squid-users/201308/0358.html>). 

Some SMP-unaware features continue to work in SMP mode (e.g., DNS
responses are going to be cached by individual workers), but their
performance suffers from the lack of synchronization and they require
more resources due to duplication of information (e.g., each worker may
independently resolve and cache the IP of the same domain name). Some
SMP-unaware features break badly (e.g., ufs-based cache_dirs become
corrupted) unless squid.conf conditionals are used to prevent such
breakage. Some SMP-unaware features will appear to work but will do so
incorrectly (e.g., delay pools will limit bandwidth on per-worker basis,
without sharing traffic information among workers and without dividing
bandwidth limits among workers).

>
>
>
> --
> View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-multithread-tp4680488p4680490.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-- 
Cats - delicious. You just do not know how to cook them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161114/51c824b1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161114/51c824b1/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161114/51c824b1/attachment-0001.sig>

More information about the squid-users mailing list