Hi Alex,
Do we have a recent squid ver 6 snapshot build available for testing? Looking for something that includes the patch from the PR to introduce the ip_bind_address_noport socket option on outbound TCP connections, I dont see any new builds after Sep 6th.
http://www.squid-cache.org/Versions/v6/
We have been using the last commit (prior to merge) from my branch on a few canary instances and have observed a memory leak with squid 6.0.0. The memory usage by squid with that code has grown by almost 20G over the last 2+ months, while other v5.5 squids (with a local patch for adding that socket option) have not had that significant of an increase.
The following config knobs were tried and did not make much of a difference with respect to concurrent outbound TLS sessions across the workers. The docs say the default sslproxy_session_cache_size is 2 MB, how high can we go? Are there any other knobs we can try to improve session reuse for HTTPS reqs ? (without enabling squid cache)
sslproxy_session_cache_size 10 MB
tls_outgoing_options options=NO_TICKET
tls_outgoing_options options=NO_TICKET
> Agree, it might not make sense to increase the complexity with sharing
> socket among the workers. Was thinking more on the lines of a hashmap
> that the coordinator could use to pick workers that already have a TCP
> connection to the destination being requested, instead of having the
> workers themselves share connection details.
Coordinator does not receive/see regular HTTP traffic. If we start
routing HTTP transactions through that process, it may become the
bottleneck itself _and_ will introduce additional overheads for passing
descriptors to workers. From performance point of view, the model with
one "routing" task doling work to workers works best (and is commonly
used) in threaded applications, but Squid is not threaded at that level.
> Most of the TCP connections are for HTTPS reqs, w/o TLS termination at
> the squid. Does squid currently support a TLS session cache ?
Yes, there is some support for worker-specific TLS session caching, with
directives like sslproxy_session_cache_size, tls_outgoing_options
options=NO_TICKET (for outgoing sessions IIRC) and https_port
sslflags=NO_SESSION_REUSE and https_port sslcontext (for incoming sessions).
HTH,
Alex.
> If you are dealing with TLS sessions as well, then we should add a
> shared memory TLS session cache that all workers can tap into.
>
>
> Cheers,
>
> Alex.
>
> > On Tue, Jun 21, 2022 at 2:11 PM Alex Rousskov wrote:
> >
> > On 6/19/22 12:48, Praveen Ponakanti wrote:
> >
> > > What is the process to have this code patch upstreamed for
> future
> > squid
> > > versions?
> >
> > In short, just post a quality pull request on GitHub (or find
> somebody
> > who can guide your code towards official acceptance for you). For
> > details, please see
> https://wiki.squid-cache.org/MergeProcedure
> <https://wiki.squid-cache.org/MergeProcedure>
> > <https://wiki.squid-cache.org/MergeProcedure
> <https://wiki.squid-cache.org/MergeProcedure>>
> >
> >
> > Thank you,
> >
> > Alex.
> >
> >
> > > On Fri, May 20, 2022 at 9:31 PM Amos Jeffries
> > <squid3@xxxxxxxxxxxxx <mailto:squid3@xxxxxxxxxxxxx>
> <mailto:squid3@xxxxxxxxxxxxx <mailto:squid3@xxxxxxxxxxxxx>>
> > > wrote:
> > >
> > > On 20/05/22 19:44, Praveen Ponakanti wrote:
> > > > Hi Alex,
> > > >
> > > > Thanks for going through several steps to help mitigate
> > src port
> > > > exhaustion. We are looking to achieve 400-500% more
> > > > concurrent connections if we could :) as there is a
> > > significant buffer
> > > > on the available CPU.
> > >
> > > Then you require at least 4, maybe 5, IP addresses to
> handle
> > that many
> > > concurrent connections with Squid.
> > >
> > >
> > > We would like to investigate going beyond the ephemeral port
> > range for
> > > some specific destination IP:PORT addresses. For that it
> appears
> > squid
> > > does not round-robin requests if we use multiple
> > tcp_outgoing_addresses.
> > > We could use ACL’s to pick a different outbound IP based
> on the
> > clients
> > > source IP, however that is not very ideal in our
> environment as our
> > > clients aren’t always equally split by subnet. However, if
> we could
> > > split by the client’s source port that might help achieve
> this. For
> > > example something like:
> > >
> > >
> > > acl pool1 clientport 0-32768
> > >
> > > acl pool2 clientport 32769-65536
> > >
> > >
> > > tcp_outgoing_address 10.1.0.1 pool1
> > >
> > > tcp_outgoing_address 10.1.0.2 pool2
> > >
> > >
> > > Squid's ACLs currently do not allow filtering by the
> client's source
> > > port. We could look into a separate patch to add this
> > functionality to
> > > squid’s ACL code if that makes sense. Or is there a better
> way to
> > > achieve this?
> > >
> > >
> > > Thanks
> > >
> > > Praveen
> > >
> > >
> > > > The option to use multiple tcp_outoing_addresses
> appears to be
> > > promising
> > > > along with some tweaks to the TCP timeouts. I guess we
> > could use
> > > ACLs to
> > > > pick a different outbound IP based on the
> requesting client's
> > > prefix. We
> > > > had not considered that option as the ephemeral
> ports were
> > no longer
> > > > available to other applications when squid uses most of
> > them with a
> > > > single outbound IP configured. We are also looking to
> > modify the
> > > code to
> > > > use the IP_BIND_ADDRESS_NO_PORT sockopt as that
> could help
> > delay
> > > port
> > > > assignment with the bind() call on the outbound TCP
> > sessions (to
> > > > hopefully allow access to the 4-tuple on the socket).
> > >
> > > Patches welcome.
> > >
> > > However, please be aware that use of the 4-tuple is
> often no
> > different
> > > from the 3-tuple since the dst-port is typically identical
> > for all
> > > outgoing traffic to a given dst-IP.
> > >
> > >
> > > Cheers
> > > Amos
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
