Re: steady peer connection pool

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.

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

> NP: It would be beneficial to shove out a small
> dummy request such as OPTIONS to ensure that the server is aware of it
> being a legit connection and able to log things like Squid UA instead of
> treating as part of a DoS.

Yes, I was thinking about OPTIONS as well, especially when the
proxy/server on the other side of the connection is not under the same
administrative control and cannot be told to treat these connections
nicely (not my specific use case, but I am sure that would happen sooner
or later).

The other three features you listed all sound promising and may help in
other aspects of this and many other setups.

Thank you,

Alex.
Received on Sat Sep 21 2013 - 22:49:27 MDT