> Спасибо, почти то, что нужно. Только не совсем понятен механизм определения
> загруженности бекенда (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@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru