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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to