4 ms·
In AWS, achieving peak theoretical performance requires queueing & pooling jobs of specific sizes. You are literally going to suffer costly bad performance if y
by peterwwillis 9y ago
In AWS, achieving peak theoretical performance requires queueing & pooling jobs of specific sizes. You are literally going to suffer costly bad performance if you don't implement and limit backlogs and concurrency.
This is basically just "stacks and queues" in a general sense, most often seen as wait-and-retry in an application, and rate controls in a service.
To do this and survive cascading failures you have to know the limits of each part of your stack and implement rate controls for each. An easy way to do this is to design network services that serve requests for applications via an API, rather than giving apps unfettered access to network resources. You can allow applications access to your network service and change rate controls for each app as needed. Alternately, you can add limits to your apps' layers at design time, rather than having to discover the limits by performance testing or trial-and-error.
The author wants a universal solution, which is a bit like saying, please solve "traffic" for me for every mode of transportation. Airplanes have different traffic than cars, so their designs will differ, although they all involve an agent that coordinates traffic flows according to a set of rules.
- evanj 9y agoI agree that a universal solution sounds difficult. However, it seems like it should be possible to have something that works "well enough" for some (broad) class of servers. My example is TCP, which does a "good enough" job of controlling the flow of packets over a wide range of networks.