4 ms·
If you can assume that any given client will consume a relatively set range of server resources to the point where random load balancing evenly distributes load
by padobson 11y ago
If you can assume that any given client will consume a relatively set range of server resources to the point where random load balancing evenly distributes load for large numbers of clients, then why not just have the front-end servers return some sort of "server's full" header and tell the client to try another? Are the extra requests so expensive? Or is using the random distribution simply a case of "This works, so why bother with non-random methods?"
- ma2rten 11y agoYour idea actually only makes sense if load is not equally balanced. If it is equally balanced that means all servers will become "full" at approximately the same time. Unless you exchange information about load between servers (which is difficult) this means a client will have to try a large number of servers until it finds one that is not "full".
- LASR 11y agoMultiple network round-trips to find a 'good' back-end is undesirable. If your client is browser-side javascript, for example, then these can directly affect responsiveness and time to page usable. Random is significantly easier and cheaper to implement. As you scale your service to multiple back-ends for the first time, you pragmatically start off with a random client-side load balancer - because it is cheap and simple. Load balancing is one of those things in your product that once working to some minimum extent, nobody cares about improving. Swapping out the client side load balancer for a 'real' load balancer is the last thing on team's mind. So, you'll see a very large number of mature products continuing to use them. Last point, random-client side load balancing provides a true solution for SPOF where as in the other methods, you still have at least on SPOF somewhere in the system.