2 ms·
This article seems like it was applicable circa 2006 but not in 2023. With asynchronous request handling (non-blocking request processing), you cannot reliably
by ComputerGuru 3y ago
This article seems like it was applicable circa 2006 but not in 2023. With asynchronous request handling (non-blocking request processing), you cannot reliably calculate the "processing time" of a single request since it is only actively being serviced (and therefore preventing another request from being serviced) for a tiny fraction of the total time.
(The exception being for a request that requires no asynchronous handling from the point the GET is received on the server to the point the first byte is written to the response, but that's rarely the kind of request that's ever a bottleneck in the first place since it's basically limited to just static html.)
- deleted 3y ago[deleted]
- ynniv 3y agoAll systems respond the same way eventually. Keep multiplying your load by ten and you'll see them.
- ComputerGuru 3y agoYes but the premise of the article is that you don’t need to test under load (i.e. benchmark) - only accurately measure the time it takes to fulfill a single request.
- ynniv 3y agoYou measure the things that block, to predict when they will queue. Your async dispatcher still takes time per request. The resources that each request needs will eventually be exhausted. Your network interface isn't infinitely fast. Identify these, measure them, and you'll have a decent chance at predicting some of the problems you'll run into as things scale.