On 22/09/2013 10:49 a.m., Alex Rousskov wrote:
On 09/20/2013 09:05 PM, Amos Jeffries wrote:

1) the background neighbour probe which opens a TCP connection to the
peer then drops it should be at least saving that connection in the
pconn pool for re-use if possible. This also brings Squid more inline
with browsers which open multiple connections then leave some idle until
later use happens.
This one will indeed [partially] help with the problem I have described.
The primary difference here is that these "probe" connections would have
to be done based on the number of currently available idle connections,
and not based on time. Another difference is that we may need more than
one concurrent probe to the peer.

Maybe. There will always be churn from closing connections. Particularly since POST requests etc force an idle connection to close early. idle=N is about minimum available rather than exact count.

If we ever implement the more aggressive version, we should try to
integrate it with the peer probes.

Yes.

Amos

Reply via email to