Fair Proxy Balancer

[mobiledreamers at gmail.com]

yes it l b great if fair proxy balancer is added to nginx trunk

On Jan 31, 2008 2:31 PM, David Pratt <fairwinds at eastlink.ca> wrote:

> Hi Grzegorz. This gives me a much better idea of what to expect. Thank
> you for this. I am curious whether you have you done anything in the way
> of comparing the effectiveness of the fair proxy balancer to other
> balancing schemes like haproxy or lvm. Speed is a big factor for
> deployments so hoping speed will be good with the simplicity that this
> option presents. Many thanks.
>
> Regards,
> David
>
> Grzegorz Nosek wrote:
> > On Thu, Jan 31, 2008 at 01:29:32PM -0400, David Pratt wrote:
> >> Hi Grzegorz. I appreciate your explanation. It would be more convenient
> >> to compile as an option since I am using an automated build process. If
> >> it is self contained, can you forsee any problems building with most
> >> current 0.5.x branch or is this strictly 0.6.x? Also, what is the
> >> request threshold that triggers the issue with round robin issue that I
> >> am aware. Many thanks.
> >
> > The module works with 0.5.x as well as 0.6.x (if it doesn't work for
> > you, please mail me with a bug report).
> >
> > There's no threshold per se, it's just that the original load balancer
> > directs requests strictly round robin, i.e. 0-1-2-3-0-1-2-3 etc. This
> > ensures that every backend gets the same number of requests.
> >
> > upstream_fair always starts from backend 0 and works its way up until it
> > finds an idle peer (more or less). If your load effectively uses a
> > single backend at one time, it'll always be backend 0. If it uses the
> > power of two backends, they'll be 0 and 1 etc. Thus the first backend
> > will always have the most requests served, the second one will have more
> > than the third etc.
> >
> > Best regards,
> >  Grzegorz Nosek
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080201/0c0a1ea4/attachment.html>