Re: автоматическое назначе ние веса бекендам

[Olexander Shtepa <isk@xxxxxxxxxxxx>]

> Спасибо, почти то, что нужно. Только не совсем понятен механизм определения
> загруженности бекенда (weighted least-connection round-robin). Что понимать
> под least-connection? TCP-задержку, время http-отклика, или что-то иное
> (ping?)?

Надо было по ссылка походить - http://nginx.localdomain.pl/wiki/UpstreamFair :
upstream_fair has several modes of operation, making it suitable for diverse 
environments. 
default
 The default mode is a simple WLC-RR (weighted least-connection round-robin) 
algorithm with a caveat that the weighted part isn't actually too fair under 
low load (under high load it all averages out, anyway). This is the 
upstream_fair many of you already know. Other modes are the result of recent 
development so grab a copy before your competition does ;) 
no_rr
 If you wish, you may disable the "-RR" part, which means that whenever the 
first backend is idle, it's going to get the next request. If it's busy, the 
request will go to the second backend unless it's busy too etc. 
 Why would you want to disable round-robin? A particularly good reason is when 
you're still unsure about how many backends you need and are starting the 
backends on demand (e.g. using my Spawner?). With round robin enabled, the 
requests will get distributed roughly equally between backends, so all backends 
will have to run all the time (even if you actually use 10% of their capacity). 
When you disable round-robin, you are going to use exactly as many backends as 
you really need. 
weight_mode=idle no_rr
 However, by default an "idle" backend (a rather central concept in 
upstream_fair) is exactly that: a backend with zero requests being processed. 
Thus two concurrent requests will cause two backends to start up even if one 
would easily handle it. Enter weight_mode=idle. 
 This mode redefines the meaning of "idle". It now means "less than weight 
concurrent requests". So you can easily benchmark your backends and determine 
that X concurrent requests is the maximum for you (e.g. while keeping latency 
below a limit or maximising throughput), set the weight to that amount and 
that's it. upstream_fair will balance between the minimum possible pool of 
backends, adding new ones as the load increases. Although the backends are all 
considered "idle" by the main algorithm, they are still scheduled using the 
least-connection algorithm (without the weighted part). 
weight_mode=peak
 On the opposite end of the scale, you may find out that your backends cannot 
keep up with the load and you'd rather return 50x errors to the client than try 
to process too many requests (you might e.g. have a funky tiered load-balancing 
setup or try to keep latency under control). 
 Simply enable weight-mode=peak and be sure that Nginx will never send more 
than weight requests to any single backend. If all backends are full, you will 
start receiving 502 errors.

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru