Re: steady peer connection pool

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.

The idle=N option is very similar to what we need, but has the wrong
focus on keeping already opened connections, rather than making sure
that N connections are ready for use at all times.

If we ignore the startup problem (no connections at all) and that pconns
in the idle pool get closed (for various reasons), then the combination
of probes and idle=N will be the right solution. Unfortunately, those
things are at the core of the problem and cannot be ignored.

BTW, I would not be surprised if some setups using idle=N would prefer
to use hot=N instead (or whatever we end up calling the proposed feature).

Thank you,

Alex.
Received on Sat Sep 21 2013 - 23:14:35 MDT