46 messages in ru.sysoev.nginxRe: Fair Proxy Balancer
FromSent OnAttachments
Adam ZellNov 22, 2007 1:38 pm 
Janko HauserNov 22, 2007 2:16 pm 
Alexander StauboNov 22, 2007 3:06 pm 
Ezra ZygmuntowiczNov 22, 2007 4:05 pm 
Jodok BatloggNov 22, 2007 11:40 pm 
Grzegorz NosekNov 23, 2007 4:37 am 
Janko HauserNov 23, 2007 5:43 am 
David PrattJan 30, 2008 7:26 pm 
Alexander StauboJan 31, 2008 2:50 am 
MarkJan 31, 2008 3:07 am 
Alexander StauboJan 31, 2008 3:10 am 
David PrattJan 31, 2008 5:23 am 
David PrattJan 31, 2008 5:31 am 
Alexander StauboJan 31, 2008 5:55 am 
Grzegorz NosekJan 31, 2008 8:45 am 
David PrattJan 31, 2008 9:29 am 
Grzegorz NosekJan 31, 2008 10:28 am 
David PrattJan 31, 2008 2:31 pm 
mobi...@public.gmane.orgFeb 1, 2008 11:19 pm 
Rob MitzelFeb 5, 2008 4:50 pm 
Rob MitzelFeb 5, 2008 4:53 pm 
David PrattFeb 6, 2008 6:06 am 
Grzegorz NosekFeb 6, 2008 7:40 am 
David PrattFeb 6, 2008 10:44 am 
Ezra ZygmuntowiczFeb 6, 2008 12:00 pm 
Andrew ReynhoutFeb 6, 2008 9:23 pm 
David PrattFeb 8, 2008 5:49 am 
Alexander StauboFeb 8, 2008 7:29 am 
Grzegorz NosekFeb 8, 2008 7:47 am 
Alexander StauboFeb 8, 2008 4:33 pm 
Grzegorz NosekFeb 9, 2008 1:13 am 
Matt ConwayMay 5, 2008 9:21 am 
Grzegorz NosekMay 5, 2008 12:26 pm 
Rt IbmerMay 6, 2008 6:02 am 
Grzegorz NosekMay 6, 2008 6:22 am 
Rt IbmerMay 6, 2008 8:12 am 
Grzegorz NosekMay 6, 2008 9:00 am 
Rt IbmerMay 6, 2008 9:44 am 
Kiril AngovMay 6, 2008 10:00 am 
BJ ClarkMay 6, 2008 10:19 am 
Jay ReitzMay 6, 2008 11:05 am 
Rt IbmerMay 6, 2008 11:30 am 
Rt IbmerMay 6, 2008 11:33 am 
David PrattMay 6, 2008 11:34 am 
Rt IbmerMay 6, 2008 11:50 am 
David PrattMay 6, 2008 1:50 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: Fair Proxy BalancerActions...
From:Grzegorz Nosek (grze@public.gmane.org)
Date:Nov 23, 2007 4:37:53 am
List:ru.sysoev.nginx

Hi,

2007/11/23, Alexander Staubo <alex@public.gmane.org>:

One question, how is the busy state determined? In case of zeo each backend client can take some defined number of requests in parallel, how is such a case handled?

Should work out of the box, distributing the load equally. You may wish to specify weight for each backend but if all are equal, this should have no effect.

I have not studied the sources, but I expect it will pick the upstream with the fewest number of current pending requests; among upstreams with the same number of concurrent requests, the one picked is probably arbitrary.

The scheduling logic looks like this: - The backends are selected _mostly_ round-robin (i.e. if you get 1 req/hour, they'll be serviced by successive backends) - Idle (no requests currently serviced) backends have absolute priority (an idle backend will be always chosen if available) - Otherwise, the scheduler walks around the list of backends (remembering where it finished last time) until the scheduler score stops increasing. The highest scored backend is chosen (note: not all backends are probed, or at least not always). - The scheduler score is calculated roughly as follows (yes, it could be cleaned up a little bit):

score = (1 - nreq) * 1000 + last_active_delta; if (score < 0) { score /= current_weight; } else { score *= current_weight; }

nreq is the number of currently processed requests last_active_delta is time since last request start _or_ stop (serviced by this backend), in milliseconds current_weight is a counter decreasing from the backend's weight to 1 with every serviced request

It has a few properties which (I hope) make it good: - penalizing busy backends, with something like a pessimistic estimate of request time - rewarding backends which have been servicing a request for a long time (statistically they should finish earlier) - rewarding backends with higher weight more or less proportionally.

Please give the module a try and report any issues you might find.