Re: steady peer connection pool

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? Let's say we split the parameter into an high and
a low watermark (min-idle and max-idle). 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? After all,
it's just the way Apache handles the idle workers pool, so it's also
pretty well understood by system administrators.

  Kinkie
Received on Sun Sep 22 2013 - 06:51:44 MDT