Event Loop vs Multithread blocking IO

http events io blocking

Unknown · Jun 5, 2009 · Viewed 7.1k times · Source

I was reading a comment about server architecture.

In this comment, the person says 3 things:

The event loop, time and again, has been shown to truly shine for a high number of low activity connections.
In comparison, a blocking IO model with threads or processes has been shown, time and again, to cut down latency on a per-request basis compared to an event loop.
On a lightly loaded system the difference is indistinguishable. Under load, most event loops choose to slow down, most blocking models choose to shed load.

Are any of these true?

And also another article here titled "Why Events Are A Bad Idea (for High-concurrency Servers)"

Answer

Typically, if the application is expected to handle million of connections, you can combine multi-threaded paradigm with event-based.

First, spawn as N threads where N == number of cores/processors on your machine. Each thread will have a list of asynchronous sockets that it's supposed to handle.
Then, for each new connection from the acceptor, "load-balance" the new socket to the thread with the fewest socket.
Within each thread, use event-based model for all the sockets, so that each thread can actually handle multiple sockets "simultaneously."

With this approach,

You never spawn a million threads. You just have as many as as your system can handle.
You utilize event-based on multicore as opposed to a single core.