Re: steady peer connection pool

On 09/22/2013 12:51 AM, Kinkie wrote:
> On Sun, Sep 22, 2013 at 1:14 AM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 09/21/2013 04:38 AM, Kinkie wrote:
>>> Amos already answered very fully.
>>> To me, this just seems a worthwile optimization.
>>> Background neighbor probe with dummy request and cache_peer idle=num
>>> seems reasonable in terms of effectiveness and implementation effort;
>>
>> Unless we bombard a peer with new connections every few hundred
>> milliseconds, the effectiveness of the above combination (for the
>> problem at hand) would be close to zero. To solve the problem, the
>> criteria for opening a new connection should be "not enough opened
>> connections" rather than "we have not probed that peer for a while".
>> While you can emulate the former by using small timeouts, the overheads
>> make such emulation prohibitively expensive.

> Why do you say that?

I am not sure which part of my response you are referring to, but I hope
you agree that probing a peer proxy every few hundred milliseconds is
prohibitively expensive.

> Let's say we split the parameter into an high and
> a low watermark (min-idle and max-idle).

This goes beyond frequent probe + idle=N solution that you proposed and
I was commenting on.

> In the pconn cleanup, if
> we're above max-idle, we start closing some pconns, if we're below we
> start more aggressively "probing" forcibly using new conns (see point
> 1), and adding these to the pconns pool. Sure, it won't _fix_ the
> problem but at least it'll make it a bit better, won't it?

Perhaps, but I would like to arrive at a solution that will fix the
problem. Based on the discussion with Amos, it looks like a "proper"
idle=N port to Squid3 might be it.

Thank you,

Alex.
Received on Mon Sep 23 2013 - 00:18:29 MDT