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