Hi Pavlos, On Fri, Oct 21, 2016 at 03:01:52PM +0200, Pavlos Parissis wrote: > > 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. > > > > It is way better:-), see Marcin's response.
Ah sorry, I missed it. Indeed it looks much better, but we don't have the reference (no reuse) on this graph. If the no reuse shows 10 times higher average times, then it means "safe" reuse brings a 10 times improvement and "always" brings 20 times so it's a matter of choice. However if safe does approximately the same as no reuse, for sure "always" is almost needed. > >>> 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. > > Connection will be aborted by haproxy sending TCP RST? As much as possible yes. The principle is to let the client retry the request (since it is the only one knowing whether it's safe or not). > > 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". > > Which field on the log do we need to watch? Tq? Tw (time spent waiting in the queue), Tc (time spent getting a connection), and of course the termination flags, everything with a C or Q on the second char needs to be analysed. > > 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. > > > Thanks a lot for yet another reach in information replies. You're welcome. Please note that the reuse mechanism is not perfect and can still be improved. So do not hesitate to report any issue you find, we definitely need real-world feedback like this. I cannot promise that every issue will be fixed, but at least we need to consider them and see what can be done. Cheers, Willy
