On 29/04/11 19:42, Mathias Fischer wrote:
On 28/04/11 15:12, Amos Jeffries wrote:
On 28/04/11 20:19, Mathias Fischer wrote:
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.
I also compared 2.6 and 3.0 -- I see the same differences as between 2.7
and 3.1.
> 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.
I was assuming, that in order to achieve connection pinning, also the
connection handling to cache peers has been changed.
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).
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.
OK. I will keep an eye on that.
In the meantime we will investigate the impact of a decreased pconn
timeout.
Kind regards,
Mathias
As a side note. Squid does not obey the HTTP "Keep-Alive:" header TTLs.
Any patches to fix that omission are very welcome.
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
