<div dir="ltr">
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Hi Alex,</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Thanks for all the help from the squid dev group with upstreaming the enhancement to scale up outbound TCP sessions on Linux with the IP_BIND_ADDRESS_NO_PORT sockopt flag. Our canary instances have been doing great the last few weeks with the code patch prior to merge.</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">A few followup questions (not urgent) :</p>
<ul class="gmail-ul1" style="list-style-type:hyphen">
<li class="gmail-li1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue""><span class="gmail-s1" style="font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:normal"></span>Do we know which 5.x version will include the patch? I do not see it listed in the change log for <span style="color:rgb(36,41,47);font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:12px;white-space:pre">squid-5.7</span>.</li>
<li class="gmail-li1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue""><span class="gmail-s1" style="font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:normal"></span>We have a large number of workers (30) to help with handling a high RPS. However, TCP session reuse does not seem to be optimal even with server_persistent_connections enabled as a new outbound session would have to be opened up if the request is proxied by a kid worker that doesn’t already have a connection to that destination. Is there something that can be done to improve this with later versions of squid? Would be glad to help out if anyone has some suggestions.</li>
</ul><div><font face="Helvetica Neue">Thanks</font></div><div><font face="Helvetica Neue">Praveen</font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 21, 2022 at 2:11 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/19/22 12:48, Praveen Ponakanti wrote:<br>
<br>
> What is the process to have this code patch upstreamed for future squid <br>
> versions?<br>
<br>
In short, just post a quality pull request on GitHub (or find somebody <br>
who can guide your code towards official acceptance for you). For <br>
details, please see <a href="https://wiki.squid-cache.org/MergeProcedure" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/MergeProcedure</a><br>
<br>
<br>
Thank you,<br>
<br>
Alex.<br>
<br>
<br>
> On Fri, May 20, 2022 at 9:31 PM Amos Jeffries <<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a> <br>
> wrote:<br>
> <br>
> On 20/05/22 19:44, Praveen Ponakanti wrote:<br>
> > Hi Alex,<br>
> ><br>
> > Thanks for going through several steps to help mitigate src port<br>
> > exhaustion. We are looking to achieve 400-500% more<br>
> > concurrent connections if we could :) as there is a<br>
> significant buffer<br>
> > on the available CPU.<br>
> <br>
> Then you require at least 4, maybe 5, IP addresses to handle that many<br>
> concurrent connections with Squid.<br>
> <br>
> <br>
> We would like to investigate going beyond the ephemeral port range for <br>
> some specific destination IP:PORT addresses. For that it appears squid <br>
> does not round-robin requests if we use multiple tcp_outgoing_addresses. <br>
> We could use ACL’s to pick a different outbound IP based on the clients <br>
> source IP, however that is not very ideal in our environment as our <br>
> clients aren’t always equally split by subnet. However, if we could <br>
> split by the client’s source port that might help achieve this. For <br>
> example something like:<br>
> <br>
> <br>
> acl pool1 clientport 0-32768<br>
> <br>
> acl pool2 clientport 32769-65536<br>
> <br>
> <br>
> tcp_outgoing_address 10.1.0.1 pool1<br>
> <br>
> tcp_outgoing_address 10.1.0.2 pool2<br>
> <br>
> <br>
> Squid's ACLs currently do not allow filtering by the client's source <br>
> port. We could look into a separate patch to add this functionality to <br>
> squid’s ACL code if that makes sense. Or is there a better way to <br>
> achieve this?<br>
> <br>
> <br>
> Thanks<br>
> <br>
> Praveen<br>
> <br>
> <br>
> > The option to use multiple tcp_outoing_addresses appears to be<br>
> promising<br>
> > along with some tweaks to the TCP timeouts. I guess we could use<br>
> ACLs to<br>
> > pick a different outbound IP based on the requesting client's<br>
> prefix. We<br>
> > had not considered that option as the ephemeral ports were no longer<br>
> > available to other applications when squid uses most of them with a<br>
> > single outbound IP configured. We are also looking to modify the<br>
> code to<br>
> > use the IP_BIND_ADDRESS_NO_PORT sockopt as that could help delay<br>
> port<br>
> > assignment with the bind() call on the outbound TCP sessions (to<br>
> > hopefully allow access to the 4-tuple on the socket).<br>
> <br>
> Patches welcome.<br>
> <br>
> However, please be aware that use of the 4-tuple is often no different<br>
> from the 3-tuple since the dst-port is typically identical for all<br>
> outgoing traffic to a given dst-IP.<br>
> <br>
> <br>
> Cheers<br>
> Amos<br>
> _______________________________________________<br>
> squid-users mailing list<br>
> <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
> <mailto:<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a>><br>
> <a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
> <<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a>><br>
> <br>
> <br>
> _______________________________________________<br>
> squid-users mailing list<br>
> <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
> <a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div>