Re: steady peer connection pool

On 09/21/2013 08:17 PM, Amos Jeffries wrote:
> I'm not proposing that as a full fix but as one soure of reducing the
> total handshake load and delays. Even one probe per second re-used is
> one user happier.

Sure, but one probe per second is quite a lot of probing activity,
especially for an otherwise idle kid Squid! The parent node receiving
all those probes from child Squids would not be very happy. And even one
probe per second still does not completely solve the cold start problem.

> Also, is this peer actually having connections re-used? or closing them
> constantly?

Yes. Both proxies in question are reusing connections as much as Squid3
can reuse them. As you know, there are many cases where Squid cannot
reuse a connection. And when a child Squid3 cannot reuse a connection it
closes an idle one. Furthermore, network problems and Squid reboots can
kill connections. On top of that, SMP multiplies the problem by 10
(because workers do not share outgoing connections).

> With a peer under relatively constant load the connection count should
> accumulate to a steady state where existing connections are being
> finished with fast enough to handle the new requests.

Agreed. The problem I am trying to address is a "[repeated] cold start"
problem, essentially. There is no constant load between those Squids,
but each time an end user becomes active, they expect (and are used to)
an "instant" response. They do not want to wait a few seconds.

>> 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.

> Huh? no. idle=N is focused on having N connections _open_ for immediate
> use.

Sorry, I was mislead by idle=N documentation. The Squid 2.7.5 code I
just checked indeed sometimes opens new connections to reach the idle=N
target. Unfortunately, it opens them only when a connection is already
needed (too late for my use case) and may even close an idle connection
despite running low, but it is overall closer to what I need than I
originally thought. Perhaps more recent Squid2 releases do an even
better job.

Given Squid2 idle=N implementation, porting it to Squid3 with the
necessary adjustments would be the best solution IMO. The best
implementation/port would ensure that there are at least N idle
connections to the peer at all times, subject to pacing limits.

> If hot=N is set to a few hundred (or thousand) can you be sure the local
> firewalls etc will not block the connections as the sudden SYN flood
> appears?

No. I have already mentioned that connection opening should be paced.
Please note that Squid 2.7.5 code does not do that:

> while (idle < fs->peer->idle) {
> openIdleConn(fs->peer, domain, outgoing, tos, ctimeout);
> idle++;
> }

Again, more recent Squid2 releases may be do a better job. If we work on
porting idle=N, we will check the most recent Squid2 code, of course.

FWIW, in my use case, I anticipate a setting of idle=6 or similar.

> And how long will the Squid startup/reconfigure processes be delayed by
> perforing that many SSL handshakes in one burst?

TCP and SSL handshakes are not monolithic/blocking events so the
startup/reconfigure processes should proceed as usual for reasonable
idle=N settings.

> I note that this problem is the one being resolved by HTTP/2 framing.
> Getting that working would seem to be the best long term solution. Each
> HTTP/2 peer TCP connection handles up to 2^31 simultaneous
> request/response pairs.

HTTP/2 does not solve the "cold start" problem. We would still need
idle=1 or similar to solve that, even when/if HTTP/2 is supported.
HTTP/2 should keep N very small though, which can be helpful indeed.

Thank you,

Alex.
Received on Mon Sep 23 2013 - 00:12:09 MDT