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.
If pinning *is* involved there is no hope for a fix, that de-aggregation
of links is just how NTLM and Negotiate auth require it to work.
Amos
-- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.12 Beta testers wanted for 3.2.0.7 and 3.1.12.1Received on Thu Apr 28 2011 - 13:13:00 MDT
This archive was generated by hypermail 2.2.0 : Fri Apr 29 2011 - 12:00:05 MDT