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
