Thanks for the response!
On Mon, Mar 6, 2017 at 1:34 AM, Willy Tarreau <[email protected]> wrote:
>
> [snip]
>
> 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.
>
Interestingly, as far as I can tell, we are running into the problem
described in this forum post:
http://discourse.haproxy.org/t/backend-encryption-and-reusing-ssl-sessions/503/4
Switching the conn_data_shutw_hard call to conn_data_shutw in checks.c
decreased CPU usage completely. Forcing SSLv3 as in this email (
https://www.mail-archive.com/[email protected]/msg09105.html) also
worked.
I haven't had time to dig further, and it may certainly be client
misconfiguration, but could you shed any light on why that might be a
problem?
