Re: steady peer connection pool

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sun, 22 Sep 2013 14:23:09 +1200

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
Received on Sun Sep 22 2013 - 02:23:12 MDT

This archive was generated by hypermail 2.2.0 : Sun Sep 22 2013 - 12:00:11 MDT