On 15/10/2016 09:31 πμ, Willy Tarreau wrote: > Hi Pavlos, > > On Fri, Oct 14, 2016 at 04:33:20PM +0200, Pavlos Parissis wrote: >> Hi, >> >> I just want to drop a note and mention that http-reuse works very well >> for us: >> >> % ss -t state established '( sport = :http )'|wc -l >> 2113 >> >> % ss -t state established '( dport = :http )'| wc -l >> 408 >> >> As, you can see connections established to backend servers are much less >> than the connections from clients. In the attached graph you can see >> 24-hour pattern doesn't influence that much the number of connections to >> backend. > > That's really great, thanks for the feedback. Have you tried the other > http-reuse options ?
A workmate did the experimentation on http-reuse and I only know that 'always' worked better for us. I will ask him to provide some details. > while "always" is optimal, strictly speaking it's > not very clean if the clients are not always willing to retry a failed > first request, and browsers typically fall into that category. A real > world case can be a request dequeued to a connection that just closes. What is the response of HAProxy to clients in this case? HTTP 50N? > Of course this very rarely happens, but "very rarely" is not something > your end users will accept when they face it :-) > True, very much true. > In theory in your case, "aggressive" should do the same as "always", > though since you know your applications it will not improve anything. > However if "safe" works well enough (even if it causes a few more > connections), you should instead use it. If the gains are minimal, > then you'll have to compare :-) > > Oh, last thing, "always" is generally fine when connecting to a static > server or a cache because you don't break end-user browsing session in > the rare case an error happens. > Fortunately, our applications don't suffer from this. Applications don't store locally any session information. If a browser requests 10 HTTP requests over 4 TCP connection, those HTTP requests will be always delivered to different servers. Furthermore, we use uWSGI which does also load balancing of requests to a set of processes which do not share any information. Cheers, Pavlos
Description: OpenPGP digital signature