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
