Changes between Version 3 and Version 4 of UpstreamFair
- Timestamp:
- 11/05/08 10:24:19 (22 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
UpstreamFair
v3 v4 26 26 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 ;) 27 27 28 ==== no -rr ====28 ==== no_rr ==== 29 29 30 30 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. … … 33 33 actually use 10% of their capacity). When you disable round-robin, you are going to use exactly as many backends as you really need. 34 34 35 ==== weight -mode=idle no-rr ====36 37 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`.35 ==== weight_mode=idle no_rr ==== 36 37 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`. 38 38 39 39 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 40 40 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). 41 41 42 ==== weight -mode=peak ====42 ==== weight_mode=peak ==== 43 43 44 44 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).
