Hi Pavlos, On Wed, Oct 19, 2016 at 08:28:34AM +0200, Pavlos Parissis wrote: > > 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.
I'm not surprized that always works better, but my point is that if it's much better it can be useful to stay with it, but if it's only 1% better it's not worth it. > > 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? No, the client-side connection will simply be aborted so that the client can decide whether to retry or not. Sometimes even the first request of the connection will benefit from a retry, but normally only subsequent requests are supposed to be retried. > > 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. OK but what I meant is that if a request fails on the application side, it generally has some impact on the user's browsing session. A post which returns an error, some automatic filling of a list not being performed, etc. In browsers nowadays it's hard to force to retry a failed action and reloading the page is not always an option. For a static server if an image fails to load, that's just a minor issue and the user can always right-click on it, select "view image" and reload it. I'd suggest a rule of thumb (maybe this should be added to the doc) : watch your logs over a long period. If you don't see queue timeouts, nor request timeouts, it's probably safe enough to use "always". Each time you notice one of them, there is a small risk of impacting another client. It's not rocket science but the risks depend on the same parameters. Cheers, Willy
