It uses an event driven architecture with per CPU worker processes. The number of workers you have can be controlled by the config.
Lastly, you can't just have an event loop without also creating an entirely async platform. For an event loop to work well, all operations from file reading to network requests need to be completely async.
I completely agree with need to async. The hard part is that many operations are async without an async interface. For example memory allocation, or even memory usage if the memory was not truly allocated by malloc.
1) Client libraries you might need to use in your web service might not be available in asynchronous versions.
2) Writing blocking code is much easier to write than asynchronous code.
3) Your server code is CPU bound, so there's no benefit to an asynchronous model.
4) If your web app runs in an asynchronous server and your app crashes, it'll crash the whole server. On the other hand, in a forking model, only the client that the child is serving will be impacted; the other workers will be unaffected.
5) Memory leaks are easier to contain in a forking model, assuming the child can exit or be killed after N requests.
I actually can't think of a case where a multi-threaded/forking-only web server would be faster than that. Again, assuming complete support for async libraries used throughout the web application.
Are there any web servers that have this architecture? NodeJS obviously doesn't. *
* Actually, for maximum absurdity, it looks like Kore, the web server we are currently discussing, has this architecture
| Event driven architecture with per CPU core worker processes
So each process should be able to handle a lot of concurrent connections, just like nginx.
And I tried the websocket example, and saw only the first worker process responding whenever a websocket is created.