Hello,

Am 31.03.2017 um 19:59 schrieb Patrick Kaeding:
Okay, thanks Holger! We were hitting the maxconn limit, which is what sparked this investigation. When we were at that limit, the discrepancy between frontend and backend was higher than when I could observe it above (we restarted HAProxy to re-establish the connections and start anew).

I also realized that my `netstat` command above isn't quite right, since it is counting connections in the TIME_WAIT state, while HAProxy would only be concerned with ESTABLISHED connections, right?

So is the solution to just increase the maxconn (and/or add more HAProxy nodes)?

No, increasing maxconn seems like hiding the problem to me.
There is no good answer to this, unless you know with certainty what those connections are about. TCPdumping those idle sessions and analyzing the behavior may be needed.

Note that "option forceclose" may not have a positive effect. If a browser sees that the server does not support keepalive, it may more aggressively pre-connect which is the opposite of what you are trying to achieve.

I would suggest you to transition the configuration to a keep-alive configuration with short timeouts (like timeout http-keep-alive 1s [1]), instead of working "against" the browsers. Also, closing idle pre-connect sessions with a short "timeout http-request" [2] may also help limiting the amount of maxconn slots those browsers block.



Regards,

Lukas


[1] https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4-timeout%20http-request [2] https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#timeout%20http-keep-alive

Reply via email to