3 ms·
This. Load balancing based on count assumes every request is served in equal time and resources. I think what the article misses highlighting is that this is a
by beardedwizard 3y ago
This. Load balancing based on count assumes every request is served in equal time and resources.
I think what the article misses highlighting is that this is about stateless load balancing which improves throughput at the LB, at the cost of potentially suboptimal distribution.
The other nit I have is calling hashing random, it's not, and a lot goes into selecting hash algorithms for LB that don't result in mass movement of requests every time a server is added or removed from the pool.
If the author wants stateless balanced load and assumes all requests are equal, why not use an approach like round robin?
Beyond that, you can get into more stateful methods that look at CPU use on servers, or any other metric you like to load balance on the resource you care about, ie memory or CPU vs number of open sockets.
- hinkley 3y agoRound Robin can get weird when you have common factors between the number of subrequests for a single request and the number of servers. I’ve seen everything from certain pages reliably blowing up in prod to weird caching bugs that don’t trigger in preproduction because the same box sees all of the requests. Developers have a nasty habit of assuming a glitch or someone else changed something and if a reload fixes it they don’t note the pattern.
- beardedwizard 3y agoIn load balancing they call this persistence. You are describing a case where you should persist to the server you land on. In this scenario, unless each request is exactly the same you will end up with uneven load as some sessions persist longer than others. This can still be stateless with use of a cookie for protocols that support it but is not the idealized "round robin and every request takes same time and resources". The other alternative is a stateless app that is architected for round robin lb.