Hacker News Reader

Comment by staticassertion | Hacker News Reader

I'm not sure what you mean.

> Almost every web app.

No? My point is exactly that almost every web app is not io bound. They're just... slow. They write bad queries, they make bad usage of resources and block on requests, etc.

> Even WhatsApp scale runs on a “slow” dynamic language.

But that has nothing to do with being IO bound. Whatsapp, via Erlang, works by having tons of connections on a single box. And you can watch plenty of talks by them about how they've had to work with BEAM to get Erlang to actually be IO bound.

"IO bound" is a meme. Most people just mean "my queries are slow". Unless you're saturating your NIC, you're not io bound with regards to throughput, and unless your queries execute in ~<100ns you probably aren't IO bound on latency either.

View on HN

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.)

I'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.

Actually, 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.

I 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".

When people say IO bound in this sense, they mean that's the lower bound on what your users experience:

4G latency 50ms

AWS inter AZ latency 1ms

Thread context switch 2us

The response times from things like search APIs even at FANG companies with vast resources and highly skilled engineers are often in the hundreds of milliseconds.

Reply on news.ycombinator.com