4 ms·
You're right that most web apps aren't actually "IO bound" per se. They aren't making optimal or maximal use of either network or disk IO. However the importan
by btrask 6y ago
You're right that most web apps aren't actually "IO bound" per se. They aren't making optimal or maximal use of either network or disk IO.
However the important point is that they aren't CPU bound either. Most are "user acquisition bound" (like tens of requests per second peak). Some are more like "developer time bound" (cutting the server farm in half is not worth the cost in dev time).
Either way, using a slow development framework (including language, DB, etc.) that the developers like is a reasonable choice for what they're trying to do. (I personally wish most software was faster, but they have no reason to care what I think.)
- staticassertion 6y agoI'm in full agreement that you can prioritize other things over efficiency, and that a framework in a slower language can be the right call.
- btrask 6y agoActually, I thought about it some more. I think a server that spends 99% of its time blocked on IO is "IO bound" even if it's because no one is sending it requests. It's a very different condition than saturating the NIC, but it's still meaningfully waiting on IO. Like, the process has to be spending its time somewhere, and it doesn't know "why" it's blocked. Maybe the terminology around this could be developed some more.
- staticassertion 6y agoI think we can at least agree that the terminology is fairly broken here, people very often say IO bound when they mean something totally different, and it is extremely common to hear "X doesn't need to be fast, it's IO bound anyway".