51–60 of 124 posts
You'd give them more bread, not toast. Toast is already processed bread :).
Who is Rachel and how do her short and simple stories always hit the front-page? They're interesting but I always think they're a little _too_ simple. I mean this entire thing can be summed up with: 500s (and other errors) are returned faster than processed requests. Load-balancers will find a misbehaving server's queue empty more often and give it all the requests
Load testers can do health checks, though, right? Like wanting a 200 OK response versus just any response.
If you then move the health check into the main app, maybe it eliminates a lot of false positives but the same thing can then happen further into the stack...
Great "teaching by showing" example but I don't get the initial technical scenario; you have sophisticated (ie, not RR / random) load balancers that keep track of queues in web servers, so they have to get some information back from them (when job was completed, from HTTP response for ex), but somehow don't react to 500 errors? seems like badly configured LBs. Still scenario can be used as teaching or interview quest…
Similarly, you might have e.g. a server which is responding to a 'get all widgets in category' call by quickly responding '200 OK, no widgets found', and thus ends up sucking up all the traffic.
Great "teaching by showing" example but I don't get the initial technical scenario; you have sophisticated (ie, not RR / random) load balancers that keep track of queues in web servers, so they have to get some information back from them (when job was completed, from HTTP response for ex), but somehow don't react to 500 errors? seems like badly configured LBs. Still scenario can be used as teaching or interview quest…
I've worked on a system which communicated errors by responding with a 200 and then indicating the error in the response body! Similarly, you might have e.g. a server which is responding to a 'get all widgets in category' call by quickly responding '200 OK, no widgets found', and thus ends up sucking up all the traffic.
You don't want to use actual data, so you add a dummy account.
Someone deletes the dummy account all the servers that are working perfectly start reporting they are sick.
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…
Random balancing only works with homogenous servers.
Earlier quoted context omitted.
That model works if you have a large number of short lived requests. On the other hand, if you have a small number of long running requests that you want to distribute over a number of servers, then your load balancer needs to track which servers are busy, or you'll spend a lot of time waiting for the randomly assigned server to finish, while others are idle.
Then you design your system to always respond as quickly as possible. HTTP even has a status code for that: 202 Accepted. You put the job in a queue and return some ID or cookie to the client, possibly also an ETA. Client can then poll for results (with bounded exponential back-off), again polling is just a quick key look-up; alternatively, if you have some means to push results to clients (like via WebSockets), use…
Does anyone have a link to what she is talking about?
Earlier quoted context omitted.
Everything seems trivial once you understand it. The author seems to be good at making people understand, so that it seems trivial afterwards. Knowing nothing about load balancers, had I read your summary before Rachels article, I would probably just glossed over it, but I would not have understood its profound importance for designing load balancers. Rachel's story kept me engaged and explained the problem in a way…
I think the truth lies in the middle somewhere. I knew absolutely nothing about load balancing before reading OPs comment and the blog post, and while you’re correct that I wouldn’t have retained OPs bullet point version as well as Rachel’s, Rachel really went on at a length far beyond what was needed to tell the story / explain the concept (eg, the beach ball sized bag of bread). People need an intuitive concept and…
So my point is: There are times when efficient and to the point is called for, and there are times when it's not.
Based on how verbose this article is I think maybe her original article was misunderstood because it was a chore to sort out the junk from the content just like this one. Too much flourishing, poor pacing