Hi there,
[OFF]
This is a little off-topic I know, but it's connected to this topic in a
way...
Seeing how every now and then ppl would very much like to experiment
with different LB algorithms, I believe a more productive (altough not
the simplest) solution could be to implement some sort of "primitive"
descriptive language, markup system or other form of programmable
interface where users would be able to directly define new rules to
balance the load, based on the value of a number of accessible internal
variables.
We would still have the "base" methods, but this may also allow to
create user-defined libraries which in turn could then be shared for
others to benefit from... etc. Would be a pretty heavy-weight tool I
believe.
[/OFF]
Levente
On 12/09/2011 07:03 PM, Willy Tarreau wrote:
Hi,
On Thu, Dec 08, 2011 at 12:47:12PM +0100, Mariusz Gronczewski wrote:
2011/12/6 Wout Mertens<wout.mert...@gmail.com>:
On Dec 6, 2011, at 21:58 , Allan Wind wrote:
On 2011-12-06 21:38:40, Wout Mertens wrote:
So if you're doing HTTP load balancing for app servers, it seems to me that the
server that responded fastest last time should get the job.
HAproxy is already capturing the response times at each request so I think this
would allow for really responsive fair load balancing.
Would that algorithm not be subject to oscillations? First we
send n requests to backend 1, then we send n requests to backend
2 as 1 is now slow.
If n is big enough would this not cause cascade of backend
failures? Opposed to spreading out the load over all backends.
Hmmm good point??? Some sort of damping algorithm would be needed.
For example, the rolling response time of the last 10 requests should be used.
Additionally, the response time could change the server weight instead, and
connections would be delivered according to the normal weighing algorithm. So
when you have 2 servers and one is much faster, both servers gradually get a
weight that corresponds to their speed. In a stable situation, weight*avg
response time would be equal for all servers.
IMO weighting backends should be done independent of haproxy, there is
too many variables. Response time is particulary bad, imagine you have
some leased dedicated servers and one of them have slightly higher
ping to LB, even tho 2 servers are same your load would be unbalanced.
Agreed, response-based weighting was planned a long time ago and I realized
that it was quite hard to get right, especially when a server has been in
very bad condition and you need to send it some traffic to measure is response
time. It's a chicken-and-egg problem. It's also important to ensure that all
weights are approximately centered around a certain value so that they can
always evolve in either direction.
Then I realized that setting a low maxconn on the servers was already doing
exactly what we want : once the maxconn is reached, connections get queued,
and the faster servers get more connections than the slower ones, following
a ratio which is *exactly* their response time ratio. So if one wants to
ensure fair response times between servers, a little bit of queuing is all
what's needed.
What I would like is ability to set weight from value returned by
healthcheck (with some optional averaging) so in simplest cases
(CPU-bound app server) healthcheck would only have to return
load_average/no_cores to get fairy equal load balancing
It was planned 4 years ago but finally not implemented (only one user was
asking and finally preferred another solution). I still hope to do something
like this later, but I already know by experience that in environments where
apps and infrastructure are not managed by the same people, there will
frequently be conflicts between the teams when a server receives too few or
too much traffic : "your LB is buggy" vs "your app reports stupid weights".
But I agree there are places where it still makes sense.
Regards,
Willy
