Date: Fri, 29 Apr 2011 01:12:55 +1200
From: squid3@xxxxxxxxxxxxx
To: squid-users@xxxxxxxxxxxxxxx
Subject: Re: Persistent Connections to Parent Proxy
On 28/04/11 20:19, Mathias Fischer wrote:
Hi,
We use squid together with a content scanner connected as parent proxy
(cache_peer parent) with none of them caching any content. When
upgrading from squid 2.7 to 3.1, we observed an increased number of TCP
connections between squid and its parent. I analysed the traffic between
squid and the parent proxy (for both squid versions), and found (among
some differences in HTTP version and (Proxy-)Connection header) that the
Proxy-Connection: has never been a registered header suitable for
transmission. Squid-3 was mistakenly made to send it for a while instead
of just accept it. That bug has been fixed in recent releases.
Only Connection: shod be sent over the wire.
usage of persistent connections has changed. In squid 2.7, a persistent
connection to the parent proxy is shared for multiple origin servers,
while in squid 3.1, there is at least one connection per origin server.
Obviously, this results in a much higher total number of connections.
Hmm, I thought we corrected that the same way in both 3.1 and 2.7.
3.0 and 2.6 certainly had that behaviour.
Current 2.7 and 3.1 should have (peer_IP, domain_name) as the pconn key.
There can be multiple duplicates of course up to as many as needed to
handle peak load (moderated by how fast the peer closes them).
Is there a possibility to influence this behaviour? To me, it looks like
this is related to the introduced Connection Pinning [1] feature.
Pinning links one server FD per client connection, kind of an
independent and special type of persistence. It should not be showing
this behaviour, though yes it also will cause a multitude of server
connections.
As a workaround, I see the option to reduce the number of open
persistent connections through pconn_timeout, but this will have an
impact on other connections as well which could reduce performance.
We have a re-structuring if the conn and pconn handling coming to 3.2
shortly (a few weeks) which removes the domain name from the pconn key.
