On 21/10/2016 08:14 πμ, Willy Tarreau wrote: > 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. >
It is way better:-), see Marcin's response. >>> 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? > 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". Which field on the log do we need to watch? Tq? > 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. Pavlos
signature.asc
Description: OpenPGP digital signature
