---------------------------------------- > 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. We have the same problem in 3.2.0.1 and 3.2.0.7 Is this planned for 3.2.0.8? Thanks! Jenny
