Hi! On Wed, Mar 12, 2025 at 10:34:04PM -0400, John Lauro wrote: > As to `balance leastconn`, I don't know if it's recommended but it's > what I normally use. My backends are often not equal (some have more > horsepower (different model physical servers, different loads from vms > running on them, etc), some higher latency because of different > cities), etc... and leastconn seems like that should do the best in > balancing unequal backends, automatically giving those that respond > the fastest the most load. It would be interesting to see those > benchmarks if they set different resource capabilities on those > backends and see how they compare. Sometimes you can know and use > weight, but if that's all dynamic and you don't always know....
The case where it's not recommended is when assigning long user sessions to servers using cookies, because in this case the server is chosen based on the instant load of the server, and the user is assigned for a long period. In this case you can easily end up with many more users on the few slightly faster servers than on the other ones. Another thing is that leastconn consumes much more CPU than other algos (particularly when dealing with many threads). The reason for this is that a server has to be moved twice: once when picked (the number of connections increases) and once when released (the number of connections decreases). Not so long ago we still occasionally managed to trigger some watchdogs on it under extreme conditions. One nice alternative to leastconn is random. Random is not just random, it in fact picks a few servers (2 by default), compares their numbers of connections, and chooses the least loaded one. It's also called "power of two choices". I've found that it performs almost as well as leastconn for long connections and sometimes even better for short ones that lead to cookie-based stickiness. And it's lockless, so when using threads, it can become cheaper ;-) If your workload is really sensitive to the number of connections, I would suggest to even try "random(3)" which will compare up to 3 servers. Leastconn will always provide the lowest max number of connections on each server, but the likelyhood to see it perform better than random() decreases as the number of draws in argument to random() increases. I had performed some tests in 2019 about this: https://www.haproxy.com/blog/power-of-two-load-balancing Though by then we weren't running with massive threads like the crazy stuff we're seeing these days! Willy
