Hi guys,
On Tue, Feb 25, 2014 at 02:13:32PM +0100, Lukas Tribus wrote:
> Hi,
>
>
> > We have experimented a bit with the latest haproxies and keep-alive. We
> > rely on haproxy to set good maxconn values for our servers so they can
> > operate at full speed without becoming overloaded.
> >
> > When using multiple servers in a backend, "prefer-last-server" is
> > required to get keep-alive working, but the sessions seem to be a bit
> > too sticky - haproxy perfers putting the request on a server _queue_
> > instead of assigning it to a server that still has some capacity left.
> >
> > So we found that the average serving time increased with keep-alive.
> >
> > Suggested patch attached -- NOT TESTED PROPERLY!! -- but shows the
> > spirit of something...
>
>
> Commit 2481d167efd ("BUG/MEDIUM: backend: prefer-last-server breaks
> redispatch") probably fixes your problem as well:
>
> http://haproxy.1wt.eu/git?p=haproxy.git;a=commit;h=2481d167efd15708417a1ba68b2de35468a67358
I don't think so, here it's different since there's no redispatch.
But I disagree with the method here. For most cases, keep-alive will
be used on high latency networks where it will often be preferred to
queue than to connect to another server.
The best solution will be to have a setting of the maximum number of
queued connections before we decide to rebalance a persistent
connection. That way, users will be able to decide that they want
to rebalance before queueing or before going above 1000 queued
requests, etc... So let's have a "keep-alive-max-queue" setting
or something like this. We need to be able to leave it unlimited
by default as it is now, and obviously we also want to be able to
force to never queue. So maybe defaulting to -1 could be an option.
Regards,
Willy
