14 ms·
I am not a webdev, but isn't that a task for the loadbalancer in the first place?
by Random_ernest 6y ago
I am not a webdev, but isn't that a task for the loadbalancer in the first place?
- ciprian_craciun 6y agoUnfortunately the load-balancer is not a magic-bullet curing every issue a system has. A load-balancer can be configured to do lots of things, like for example: * limit the number of concurrent requests, and drop the others; * limit the number of concurrent requests, but queue the others (with a timeout); * distribute all requests uniformly (randomly or in round-robin fashion) to all backends; * (any combination of the above); However if the "customer" asks you to not drop or queue requests, then there is nothing the load-balancer can actually do...
- Random_ernest 6y agoI took it from the article that dropping requests was permitted (since that happens when all servers go down). So my assumption is still that a better solution is that the load balancer allows only a specific number of requests per server and rejects or caches the rest. I would even argue that requests being rejected is more understandable for the user than the website simply not being there for a certain time.
- legacynl 6y agoI think you are right, except that the article reads as if they were using a loadbalancer that wasn't in their control (a third-party service). If you can't control your loadbalancer to not pass requests when you're overloaded, the next best thing is to keep track of it on each node, and basically do what the article described.