Hacker News Reader

Comment by tombert | Hacker News Reader

I'm actually asking this sincerely; hasn't this experiment already been run with Apache vs. Nginx, with Nginx coming out literally orders of magnitude faster by using epoll and using a limited number of "real" threads?

View on HN

Well, it depends what else the server is doing besides talking to the network. Low-overhead concurrency matters when you're basically just copying data to the network, like serving up static HTML, images, or video. Particularly when clients have slow network connections, a request can take a long time with nothing much happening on the server. If most requests are mostly idle, the server can handle many more concurrent requests with lightweight concurrency.

With heavyweight computations, CPU usage will hit 100% with a small number of concurrent requests, so a thread per request will work fine. Your server will get overloaded before you have too many threads and that load needs to be shed somehow, maybe by putting more servers online.

Even if you're using async-await, using threads for heavyweight requests is recommended anyway. An async function isn't supposed to hog the CPU; instead you outsource to a thread pool.

Maybe, but for most websites Apache was never the bottleneck, it was more than enough, which is I think the point GP is making.

The performance differences between Apache and nginx are attributable to more than that one design decision.

Besides, Apache is fast enough for most use cases.

> I'm actually asking this sincerely

Why do you have to say this?

Because on the internet it can be difficult to tell the difference between someone asking the question as some kind of "gotcha!" and between someone asking a legitimate question.

I tend to be a fairly sarcastic person so when I want to make sure it's unambiguous that I'm not, I prefix my questions.

Reply on news.ycombinator.com