
ELS: latency based load balancer - mzehrer
https://labs.spotify.com/2015/12/08/els-part-1/
======
jedberg
Generally you don't want to use latency based load balancing for short lived
http/s connections when you have more than once load balancer. I had found a
paper on this once with the math but I can't find it again -- the gist of the
paper was that you need longer lived connections otherwise your load balancers
can never achieve convergence, so you just end up with a see-saw effect.

This seems like a pretty good solution, but I'm unclear as to why it is better
than JSQ with a circuit breaker (or is that basically what it is?). Maybe the
second post with the algorithm will make it clearer.

~~~
samstave
Wouldn't this be "sticky sessions" \-- meaning that if you do not have sticky
sessions you get see-saw?

Also - is it true that while you don't want to use latency based LBs
necessarily for typical webtraffic - you would want it for a streaming
service?

Finally, wouldnt ELS be far preferred for one-way streaming, like music -- but
not so much for something like gaming (even though gaming would be latency
sensitive) -- so JSQ with circuit breaker is ideal for gaming, ELS for music
and JSQ/roundrobin, if you wanted, for general web traffic?

Or am I missing too much of the puzzle?

\---

Further, it would be great to account for regional load balancing as well,
wouldnt you. So as mentioned in part 2 of the article, they take into account
expected latency round trip to the client -- where what if E in region A is <
region B? How could they do a check for E to a client when it initializes a
session?

