fixed off-by-one bug in the calculation of shm_name->len
Fix building against nginx without the --with-debug option specified.
Fixed a bug ngx_http_upstream_fair_sched_score function.
In SCHED_SCORE(nreq,delta) (((nreq) << SCHED_COUNTER_BITS) | (~(delta))) the ~(delta) would dominate the "bitwise or", making the calculated score ignore the number of requests the peer is currently processing. The fix is to perform a bitwise mask on ~(delta) so it only affect the lower 20bits. SCHED_SCORE(nreq,delta) (((nreq) << SCHED_COUNTER_BITS) | (~(delta) & SCHED_COUNTER_MAX))
Thanks to Victor Lavrenko for reporting, analysing and providing a patch.
(an exceptional use-case is the status handler but it takes care to do things safely)
Weight mode 'idle' means that a backend is considered idle when servicing less than 'weight' requests. This has special meaning when running in no_rr mode. The backends are chosen from the following groups with descending priority: - backends with 1 <= nreq <= weight (by descending nreq) - totally idle backends - all other (busy) backends This mode (idle+no_rr) is particularly suited to small setups with backends started on demand. It requires care in bigger installations, as it may overload a range of backends without ever using others. Weight mode 'peak' means that no backend may serve more than 'weight' requests at once. Once this limit is reached, nginx starts to return 502 errors. This is useful when you want to limit the load on your backends at the price of errors sent to the client (although this might be an advantage in e.g. tiered load balancer setups). So the distinct modes of upstream_fair operation are: * default * no_rr * no_rr weight_mode=idle * weight_mode=peak All other combinations are more or less pointless, at least for now.
…r of requests per upstream and per backend
Currently the only parameter is `no-rr' which disables round-robin behaviour, i.e. if you only need X backends to keep up with your peak load, backends X+1 should never receive any requests. Note that this does make the load balancer unfair as requests are definitely not distributed evenly.
The data returned is more for debugging purposes than real production monitoring, so this is still proof-of-concept stage.
upstream_fair is now completely independent from the round robin module (except of course of lots of copy-pasted code).