Hi Steven,
On Wed, Mar 01, 2017 at 04:03:17PM -0800, Steven Davidovitz wrote:
> Having hundreds of HTTP SSL health checks leads to CPU saturation.
> This patch allows HTTP health checks without any http-expect directives
> to keep the connection open for subsequent health checks. This patch
> also does not affect any TCP check code.
I think something like this could possibly work, but at least the
persistent setting should definitely be an option. Indeed, for many
people, checking the connection is as important if not more as testing
the fact that the service works behind. I can give you some examples,
such as if you check another haproxy, this last one will never quit
upon a reload or soft-stop, so your health checks will continuously
check the old process and will not detect a crash of the new one which
listens to the connections.
We could imagine having a more general option (per server, per backend?)
to indicate that HTTP checks want to be performed on persistent connections,
not just the SSL ones. In fact we could specify how many consecutive
checks are allowed over a persistent connection before renewing the
connection. That would cover your use case, allow users to set a
reasonable counter to ensure that after a few checks, the listener
is properly tested, and may be useful to some users even with pure
HTTP (eg: less logs on intermediate firewalls).
Also it is not normal at all that SSL checks lead to CPU saturation.
Normally, health checks are expected to store the last SSL_CTX in the
server struct for later reuse, leading to a TLS resume connection.
There is one case where this doesn't work which is when SNI is being
used on the server lines. Is this your case ? If so a better solution
would be to have at least two (possibly a bit more) SSL_CTX per server
as was mentionned in commit 119a408 ("BUG/MEDIUM: ssl: for a handshake
when server-side SNI changes"). This would both improve the checks
performance and the production traffic performance by avoiding renegs
on SNI change between two consecutive connections.
BTW, very good job for a first submission!
Cheers,
Willy
