Re: [squid-users] squid too many connections to cache_peers

On 16/05/11 18:34, Or Gerson wrote:
> Thanks for the help,
>
> Just some clarification to understand the logic of squid: " Squid uses as many connections to each peer as there are
> maximum parallel requests needing to go to that peer"
>
> how is it that squid has a lot less connections to each peer than the number of connections he opens to each peers?
> I mean he has 3 peers to divide the requests to. So I would have thought that the number of connections to each peer will
> Be roughly the number of connections to squid divided by 3.
>
> How is the maximum parallel requests needing to go to that peer is much higher than the number of connections to squid?
>

You will be close to reality if you think of the connections
Squid<->client as completely independent and separate from the
connections Squid<->peers. There is no way to compare numbers like that.

  Squid *multiplexes* inbound connections to outbound. With both sides
doing independent keep-alive. Both sides doing protocol-conditional
closure. Idle timeouts influenced by traffic load. And on top of that
cache replies randomly (subject to timing, disk load and CPU load)
preventing peer connections being used at all.

The only relationships we can be sure of are when unknown-length objects
in HTTP/1.0 transactions cause both server and client connections to
close. Or connection-auth pinns two links together for a short duration.

Consider a reverse-proxy dream ... serving files with 100% efficiency.
==> Thousands of client connections and *no* peer connections.

Consider the opposite ... serving files proxy-only to a very large bunch
of clients visiting random websites.
==> a handful of connections to each client, expanding out to thousands
of different domain origin servers.

Back to the behaviour of 3.0 which you are interested. The hash key used
to locate and pool idle persistent connections includes the destination
domain name (calculating it not to the peer as such, but *through* the
peer to a final origin on the other side). This makes for a overly-large
amount of parallel connections to simple hierarchy peers, but there is
no easy way to reliably avoid it in 3.0 an 3.1.
  Some comm cleanup changes scheduled to go into 3.2 series over the
next month or so will fix this along with several other design flaws in
TCP/IP handling.

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