Load balancing as a strategy is used in far more than just web-applications!<p>This article only discusses web-based load balancing, which is absolutely important, but doesn't discuss supercomputer scheduling load-balancing. Its arguably a different subject... but the concept is the same.<p>When you have 4000 nodes on a supercomputer, how do you distribute the problem such that all the nodes have something to do? Supercomputer problems are sometimes predictable (ie: matrix-multiplications), and you can sometimes "perfectly load balance without communication".<p>But in the case of web-applications, there's probably no way to really predict the "cost of performance" before you start processing the service request (what if its a Facebook request to a really old photograph? Facebook may have to pull it out of long-term storage before it can service that request. There's no real way to know at the load-balancer whether a picture-request would be in the cache or not... at least, not before you process the request to begin with!)<p>-----------<p>In any case, I think adding "Predict the computational cost, calculate the costs you distributed to different nodes, and then distribute the new load to the node with lowest computational cost given so far" is a good method that works in some applications. (All blocks in a dense matrix multiplication have the same cost, so just keep passing out subblocks to all nodes as you're working on the problem)
Software load balancing solutions have now more algorithms such as least time (nginx+ for example).
And yes some ISP cache DNS entries for a long time... But DNS load balancing should be used only on disaster scenarios to mitigate.
Decent summary but a little out-dated on DNS load balancing.<p>Major cloud services like AWS support health/status checks through DNS these days: <a href="https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-multivalue.html#rrsets-values-multivalue-associate-with-health-check" rel="nofollow">https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/re...</a><p>It's also trivial to get around the client caching issue, just set a low TTL. Perhaps in the olden days providers had stricter limits on the minimum TTL you can set, but these days you can set it practically as low as you want.<p>EDIT: as a few commenters have fairly pointed out, TTL can easily be ignored by poorly-behaved ISPs and clients, so I'll admit calling it "trivial" to get around is not exactly accurate.
I like this intro!<p>Good to see ‘random’ redefined as pick random two then assign to one with least connections, which works strictly better than either random or least connections alone.<p>Misses a couple categories that may be relevant: least hops or best transit type network-mapped balancing to get to the ideal set of servers globally, as well as a technique that not-so-simply connects the user to the geography with the fastest response for them right then.<p>While the article notes value of fewer connections for a stream, you can take a bit longer in setup for a stream to get it right, as you and the viewer will pay the price longer if you get it wrong.<p>All this gets much more complicated when balancing very large objects, as you have to consider content availability and cache bin packing among the servers you balance to.
Nice succinct writeup. Here's a great deep dive on "Practical Load Balancing with Consistent Hashing" from a Vimeo engineer (2017) [0].<p>[0] <a href="https://www.youtube.com/watch?v=jk6oiBJxcaA" rel="nofollow">https://www.youtube.com/watch?v=jk6oiBJxcaA</a>
I was explaining the DNS system and load balancing today and I kind of mixed it all up based on this wonderful link. Thanks, I will share this out with that person to undo the damage I might have done.