Re: [squid-users] Persistent Connections to Parent Proxy

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 29 Apr 2011 01:12:55 +1200

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.1
Received 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