Interns with toasters: how I taught people about load balancers • Hacker News Board

Re: Interns with toasters: how I taught people about load balancers

#121

Post by loco5niner » Mon, Apr 23, 2018, 5:31 PM UTC

MaxGabriel wrote: post #62

snovv_crash wrote: post #39

This reminds me strongly of another system of distribution, which suffers from the same effect: differential gearboxes in cars. Since the torque to all the wheels is equal, if one wheel slips it very quickly takes all of the power of the engine, since power = rotational velocity * torque. Only if the speeds are similar is the allocation of power to the wheels similar. In cars, the solution is to make sure that the po…

If I remember the movie My avoiding Vinnie correctly, is this called Positraction? Marissa Tomei’s character says positraction prevents being “stuck in the mud”, where “one tire spins, the other tire does nuthin’”

My cousin Vinnie

Re: Interns with toasters: how I taught people about load balancers

#122

Post by ttflee » Mon, Apr 23, 2018, 6:21 PM UTC

A protocol without considering the possibility of insane counterpart is doomed to DDoS the systems that utilize it.

Re: Interns with toasters: how I taught people about load balancers

#123

Post by Groxx » Mon, Apr 23, 2018, 8:09 PM UTC

grosjona wrote: post #22

That's why I like random load balancing. If each machine is powerful enough and can handle a few thousand users then the distribution averages out. Smart load balancers are only really necessary if you have inefficient servers that can't handle more than 100 connections per second and they're difficult to get right. If you toss a coin 10 times, you're much more likely to get >=80% heads than if you were to toss that…

Is this better than round-robin somehow?

Re: Interns with toasters: how I taught people about load balancers

#124

Post by cecilpl2 » Tue, Apr 24, 2018, 4:11 AM UTC

ithkuil wrote: post #107

cecilpl2 wrote: post #80

I see that on my continuous integration system. We use Teamcity with ~50 agents for build tasks that take 20-30 minutes. Each agent can only be running a single task. During the day, all agents are busy and the queue fills up with 30 or so pending tasks. If one agent gets into a bad state where, say, it fails to checkout from source control and fails within the first 20 seconds of a build, then it will very quickly c…

> this particular failure mode actually becomes more common the more agents you add I'm surprised. I would expect the length of the pending job queue to also have an impact on this failure _mode_ (as opposed to the failure _cause_), and the queue length is inversely proportional to the number of agents, flooring to 0 when you have to many agents than necessary to deal with peak demand. If the bad agents (I'm assuming…

That is a good point and I like the visual metaphor of bad agents "floating on top of the pool".

I was considering the fairly narrow problem domain between say 20 and 40 agents, and the queue fills up to perhaps 50 pending tasks mid-day. You are correct in the case that once you add enough agents to keep the queue empty, then additional agents reduce the fail chance.

Sadly, though, the CI system I use (Teamcity) prioritizes agents that have a history of completing that particular task the fastest. That's great if your agents are all different specs, but fails spectacularly in this case, where a bad agent will be selected above a good one.