Ruby Forum NGINX > Re: Fair Proxy Balancer

Hi  Grzegorz - thanks for this module. It looks very nice. Can you 
explain how you keep track of how busy a backend server is? In other 
words, what do you use to determine its performance?

In our case we would like to use your fair proxy balancer so that 
machines that are responding faster get more requests than slower 
machines.

For instance, on of our upstream servers runs on the same machine as 
nginx.  From nginx's logs we can see that local upstream usually 
responds about 3-5ms faster than the other upstreams because it doesn't 
have to go over the local network to reach the upstream in that case.

So if I was using 'fair' would it realize 'hey upstream x is completing 
requests 3-5ms faster than upstreams y and z so I'm going to route more 
requests to upstream x"?  Or does your module not take that measure into 
account?

Early on while our traffic is still ramping up, requests may come in at 
a slow rate to the point where all requests could be served faster by 
the local upstream, with the other upstreams being available in case 
traffic should spike or in case one of the other upstreams goes down. In 
that scenario is it possible that your module would wind up sending all 
traffic to just the local instance if its ms response times were better 
than the other upstreams (I would not mind if it would, just trying to 
understand how it 'thinks' better). Thanks!


      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now. 
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

On Tue, May 06, 2008 at 06:03:06AM -0700, Rt Ibmer wrote:
> Hi  Grzegorz - thanks for this module. It looks very nice. Can you explain how you keep track of how busy a backend server is? In other words, what do you use to determine its performance?
> 
> In our case we would like to use your fair proxy balancer so that machines that are responding faster get more requests than slower machines.
> 
> For instance, on of our upstream servers runs on the same machine as nginx.  From nginx's logs we can see that local upstream usually responds about 3-5ms faster than the other upstreams because it doesn't have to go over the local network to reach the upstream in that case.
> 
> So if I was using 'fair' would it realize 'hey upstream x is completing requests 3-5ms faster than upstreams y and z so I'm going to route more requests to upstream x"?  Or does your module not take that measure into account?
> 
> Early on while our traffic is still ramping up, requests may come in at a slow rate to the point where all requests could be served faster by the local upstream, with the other upstreams being available in case traffic should spike or in case one of the other upstreams goes down. In that scenario is it possible that your module would wind up sending all traffic to just the local instance if its ms response times were better than the other upstreams (I would not mind if it would, just trying to understand how it 'thinks' better). Thanks!

Hi,

upstream_fair does not track the latency of requests. The timing of
responses is only used to improve round-robin behaviour.

The main factor in choosing a backend is the number of outstanding
requests, so if your local backends end up e.g. 10% faster, they'll (on
average) have 10% less requests so should be chosen 10% times more
often.

The net result should be all backends equally loaded, with the local
backends receiving 10% requests more, although without paying too much
attention to latency (apart from permanent -ENOTIME I'd really like to
see latency tracking in upstram_fair -- patches, anyone? :D)

Best regards,
 Grzegorz Nosek