Thanks Lukas, that makes sense. I will give this a shot and see what I can come up with.
Thanks, Patrick On Fri, Mar 31, 2017 at 11:18 AM, Lukas Tribus <[email protected]> wrote: > 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 > -- Patrick Kaeding [email protected]
