On 22/10/2016 08:08 πμ, Willy Tarreau wrote: > 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.
I will try to rerun the test tomorrow, which runs on production servers with real user traffic:-) > 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. > I looked at the logs for a period of 11hours and found zero occurrences of C or Q. I also didn't noticed any change on Tw and Tc timers. I will keep an eye. >>> 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. > Acked, I will report any issues we may find. Thanks, Pavlos
signature.asc
Description: OpenPGP digital signature
