4 ms·

Nope, requests could still get queued behind a dyno that's busy with a long request.

• fatbird 14y ago
  Sure, but the real issue the article identifies is that, under random routing, they need to keep doubling the number of dynos to halve the odds of bad queueing, which leads to absurd factor of 50 requirements to get back to what they had before. With round robin, the increase should be much more linear.
  • mononcqc 14y ago
    Over many requests, both should average to N requests served to each instance assuming a uniform random distribution. The real issue is being able to figure out instances to avoid when some requests end up being slow. To put it another way, ideal balancing in this case isn't about evenly splitting all requests, but evenly splitting all processing (or waiting) time. If you can guarantee that requests tend to take pretty stable and uniform time, then random or round-robin distribution should give good results. If you can't, some requests will be stuck waiting behind others and their waiting time will accumulate. You'll see worse behaviour when two or more of the bad slow requests get queued one after the other.
  • aaron695 14y ago
    I think you are right. I had to create a quick sim but it does pan out. With round robin it's going to chose the dynos most likely to have the shortest queue given the simple information available. (longest time since it got something) so it's biased to putting stuff on empty queues. Where as random picks randomly, so there's no bias to empty queues, so random should be less efficient.