<html><body><div id="nine_body_n18f819-92ad1" class="nine_body mceEditable" dir="auto" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12.0pt; line-height: 1.3; color: #1f497d;"><div class="nine-pg" dir="auto">Hi Alex </div><div class="nine-pg" dir="auto">Has I explain, by default I set those directives to off to avoid high cpu consumption. </div><div class="nine-pg" dir="auto">My doubt is enabling persistent connection will help squid to process the request more efficiently and gain more performance or not. </div><div class="nine-pg" dir="auto"><br /></div><div class="nine-pg" dir="auto">Best regards </div><div class="nine-pg blank sign" dir="auto"><br /></div><div id="nine-sign-n18f819-92ad1" class="nine_signature" dir="auto"><div class="nine-pg" dir="auto">Sent from <a style="text-decoration: none; color: #009bdf;" href="http://www.9folders.com/">Nine</a></div></div><div class="nine-pg blank msg" dir="auto"><br /></div></div><div class="quoted_output_body"><div id="quoted_header_n18f819-92ad1" class="quoted_header_editor fold" dir="auto"><hr style="border: none; height: 1px; color: #e1e1e1; background-color: #e1e1e1;" /><div dir="auto" style="border: none; padding: 3.0pt 0cm 0cm 0cm;"><span style="font-size: 11.0pt; font-family: Calibri, Arial, Helvetica, sans-serif;"><b>De:</b> Alex Rousskov <rousskov@measurement-factory.com><br /><b>Enviado:</b> quinta-feira, 16 de maio de 2024 14:56<br /><b>Para:</b> squid-users@lists.squid-cache.org<br /><b>Assunto</b> Re: [squid-users] Tune Squid proxy to handle 90k connection<br /></span></div></div><br type='attribution'></div></body></html><br><br><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="Zarafa HTML builder 1.0">
<TITLE></TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT STYLE="font-family: courier" SIZE=2>
On 2024-05-15 19:02, Andre Bolinhas wrote:<br>
<br>
> To handle this amount of traffic should I enable <br>
> client_persistent_connections and server_persistent_connections or is it <br>
> better to keep it disable?<br>
<br>
As Jonathan has already mentioned, the question is misleading because <br>
these directives default to "on" -- persistent connections are enabled <br>
by default. Modern HTTP specs enable them by default as well.<br>
<br>
Since you do not know whether persistent connections are harmful in your <br>
particular deployment environments, remove those two directives from <br>
your Squid configuration files (effectively enabling persistent <br>
connection use). There are always exceptions, but in the vast majority <br>
of cases, not specifying those directives is the best first step.<br>
<br>
If you want to research whether persistent connections are harmful in <br>
your environments, you will need to define performance metrics and <br>
experiment with all four different combinations across the two boolean <br>
directives (at least -- there are more directives that affect connection <br>
persistency). Doing this kind of research right is difficult!<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
<br>
<br>
> Best regards<br>
> <br>
> On 31/01/2022 14:52, Eliezer Croitoru wrote:<br>
>><br>
>> Hey Andre,<br>
>><br>
>> I *would not *recommend on 5.x yet since there are couple bugs which <br>
>> are blocking it to be used as stable.<br>
>><br>
>> I believe that your current setup is pretty good.<br>
>><br>
>> The only thing which might affect the system is the authentication and <br>
>> ACLs.<br>
>><br>
>> As long these ACL rules are static it should not affect too much on <br>
>> the operation, however,<br>
>> When adding external authentication and external helpers for other <br>
>> things it’s possible to see some slowdown in specific scenarios.<br>
>><br>
>> As long as the credentials and the ACLs will be fast enough it is <br>
>> expected to work fast but only testing will prove how the real world usage<br>
>> will affect the service.<br>
>><br>
>> I believe that 5 workers is enough and also take into account that the <br>
>> external helpers would also require CPU so don’t rush into<br>
>> changing the workers amount just yet.<br>
>><br>
>> All The Bests,<br>
>><br>
>> Eliezer<br>
>><br>
>> ----<br>
>><br>
>> Eliezer Croitoru<br>
>><br>
>> NgTech, Tech Support<br>
>><br>
>> Mobile: +972-5-28704261<br>
>><br>
>> Email: ngtech1ltd@gmail.com<br>
>><br>
>> *From:* André Bolinhas <andre.bolinhas@articatech.com><br>
>> *Sent:* Monday, January 31, 2022 15:47<br>
>> *To:* 'NgTech LTD' <ngtech1ltd@gmail.com><br>
>> *Cc:* 'Squid Users' <squid-users@lists.squid-cache.org><br>
>> *Subject:* RE: [squid-users] Tune Squid proxy to handle 90k connection<br>
>><br>
>> Hi<br>
>><br>
>> I will not use cache in this project.<br>
>><br>
>> Yes, I will need<br>
>><br>
>>   * ACL (based on Domain, AD user, Headers, User Agent…)<br>
>>   * Authentication<br>
>>   * SSL bump just for one domain.<br>
>>   * DNS resolution (I will use Unbound DNS service for this)<br>
>><br>
>> Also, I will divide the traffic between two Squid box instead just one.<br>
>><br>
>> So each box will handle around 50k request.<br>
>><br>
>> Each box have:<br>
>><br>
>>   * CPU(s) 16<br>
>>   * Threads per code 2<br>
>>   * Cores per socket 8<br>
>>   * Sockets 1<br>
>>   * Inter Xeron Silver 4208  @ 2.10GHz<br>
>>   * 96GB Ram<br>
>>   * 1TB raid-0 SSD<br>
>><br>
>> At this time I have 5 workers on each Squid box and the Squid version <br>
>> is 4.17, do you recommend more workers or upgrade the squid version to 5?<br>
>><br>
>> Best regards<br>
>><br>
>> *De:*NgTech LTD <ngtech1ltd@gmail.com><br>
>> *Enviada:* 31 de janeiro de 2022 04:59<br>
>> *Para:* André Bolinhas <andre.bolinhas@articatech.com><br>
>> *Cc:* Squid Users <squid-users@lists.squid-cache.org><br>
>> *Assunto:* Re: [squid-users] Tune Squid proxy to handle 90k connection<br>
>><br>
>> I would recommend you to start with 0 caching.<br>
>><br>
>> However, for choosing the right solution you must give more details.<br>
>><br>
>> For example there is an IBM reasearch that prooved that for about 90k <br>
>> connections you can use vm's ontop of such hardware with apache web <br>
>> server.<br>
>><br>
>> If you do have the set of the other requirements from the proxy else <br>
>> then the 90k requests it would be wise to mention them.<br>
>><br>
>> Do you need any specific acls?<br>
>><br>
>> Do you need authentication?<br>
>><br>
>> etc..<br>
>><br>
>> For a simple forward proxy I would suggest to use a simpler solution <br>
>> and if possible to not log anything as a starter point.<br>
>><br>
>> Any local disk i/o will slow down the machine.<br>
>><br>
>> About the url categorization, I do not have experience with ufdbguard <br>
>> on such scale but it would be pretty heavy for any software to handle <br>
>> 90k rps...<br>
>><br>
>>  It's doable to implement such setup but will require testing.<br>
>><br>
>> Will you use ssl bump in this setup?<br>
>><br>
>> If I will have all the technical and specs/requirements details I <br>
>> might be able to suggest better then now.<br>
>><br>
>> Take into account that each squid worker can handle about 3k rps <br>
>> tops(with my experience) and it's a juggling between two sides so... <br>
>> 3k is really 3k+3k+external_acls+dns...<br>
>><br>
>> I believe that in this case an example of configuration from the squid <br>
>> developers might be usefull.<br>
>><br>
>> Eliezer<br>
>><br>
>> בתאריך יום ג׳, 25 בינו׳ 2022, 18:42, מאתAndré Bolinhas <br>
>> ‏<andre.bolinhas@articatech.com>:<br>
>><br>
>>     Any tip about my last comment?<br>
>><br>
>>     -----Mensagem original-----<br>
>>     De: André Bolinhas <andre.bolinhas@articatech.com><br>
>>     Enviada: 21 de janeiro de 2022 16:36<br>
>>     Para: 'Amos Jeffries' <squid3@treenet.co.nz>;<br>
>>     squid-users@lists.squid-cache.org<br>
>>     Assunto: RE: [squid-users] Tune Squid proxy to handle 90k connection<br>
>><br>
>>     Thanks Amos<br>
>>     Yes, you are right, I will put a second box with HaProxy in front<br>
>>     to balance the traffic.<br>
>>     About the sockets I can't double it because is a physical machine,<br>
>>     do you think disable hyperthreading from bios will help, because<br>
>>     we have other services inside the box that works in<br>
>>     multi-threading, like unbound DNS?<br>
>><br>
>>     Just more a few questions:<br>
>>     1º The server have 92Gb of Ram, do you think that is needed that<br>
>>     adding swap will help squid performance?<br>
>>     2º Right now we are using squid 4.17 did you recommend upgrade or<br>
>>     downgrade to any specific version?<br>
>>     3º We need categorization, for this we are using an external<br>
>>     helper to achieve it, do you recommend use this approach with ACL<br>
>>     or move to some kind of ufdbguard service?<br>
>><br>
>>     Best regards<br>
>>     -----Mensagem original-----<br>
>>     De: squid-users <squid-users-bounces@lists.squid-cache.org> Em<br>
>>     Nome De Amos Jeffries<br>
>>     Enviada: 21 de janeiro de 2022 16:05<br>
>>     Para: squid-users@lists.squid-cache.org<br>
>>     Assunto: Re: [squid-users] Tune Squid proxy to handle 90k connection<br>
>><br>
>>     Sorry for the slow reply. Responses inline.<br>
>><br>
>><br>
>>     On 14/01/22 05:44, André Bolinhas wrote:<br>
>>     > Hi<br>
>>     > ~80k request per second  10k users<br>
>><br>
>><br>
>>     Test this, but you may need a second machine to achieve the full<br>
>>     80k RPS.<br>
>><br>
>>     Latest Squid do not have any details analysis, but older Squid-3.5<br>
>>     were only achieving >15k RPS under lab conditions, more likely<br>
>>     expect under 10k RPS/worker on real traffic.<br>
>>       That means (IME) this machine is quite likely to hit its<br>
>>     capacity somewhere under 70k RPS.<br>
>><br>
>><br>
>>     > CPU info:<br>
>>     > CPU(s) 16<br>
>>     > Threads per code 2<br>
>>     > Cores per socket 8<br>
>><br>
>>     With this CPU you will be able to run 7 workers. Setup affinity of<br>
>>     one core per worker (the "kidN" processes of Squid). Leaving one<br>
>>     core to the OS and additional processing needs - this matters at<br>
>>     peak loading.<br>
>><br>
>>     CPU "threads" tend not to be useful for Squid. Under high loads<br>
>>     Squid workers will consume all available cycles on their core, not<br>
>>     leaving any for the fancy "thread" core sharing features to<br>
>>     pretend there is another core available. YMMV. One of the tests to<br>
>>     try when tuning is to turn off the CPU hyperthreading and see what<br>
>>     effect it has (if any).<br>
>><br>
>><br>
>>     > Sockets 1<br>
>>     > Inter Xeron Silver 4208  @ 2.10GHz<br>
>>     ><br>
>><br>
>>     Okay. Doable, but for best performance you want as high GHz rating<br>
>>     on the cores as your budget can afford. The amount of "lag" Squid<br>
>>     adds to traffic and RPS performance/parallelism directly<br>
>>     correlates with how fast the CPU core can run cycles.<br>
>><br>
>><br>
>><br>
>>     HTH<br>
>>     Amos<br>
>>     _______________________________________________<br>
>>     squid-users mailing list<br>
>>     squid-users@lists.squid-cache.org<br>
>>     http://lists.squid-cache.org/listinfo/squid-users<br>
>><br>
>>     _______________________________________________<br>
>>     squid-users mailing list<br>
>>     squid-users@lists.squid-cache.org<br>
>>     http://lists.squid-cache.org/listinfo/squid-users<br>
>><br>
> <br>
> _______________________________________________<br>
> squid-users mailing list<br>
> squid-users@lists.squid-cache.org<br>
> https://lists.squid-cache.org/listinfo/squid-users<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
squid-users@lists.squid-cache.org<br>
https://lists.squid-cache.org/listinfo/squid-users<br>
</FONT>
</P>

</BODY></HTML>