Thread in an event-driven vs non-event driven web server

Question

The following two diagrams are my understanding on how threads work in a event-driven web server (like Node.js + JavaScript) compared to a non-event driven web server (like IIS + C#)

From the diagram is easy to tell that on a traditional web server the number of threads used to perform 3 long running operations is larger than on a event-driven web server (3 vs 1.)

I think I got the "traditional web server" counts correct (3) but I wonder about the event-driven one (1). Here are my questions:

1. Is it correct to assume that only one thread was used in the event-driven scenario? That can't be correct, something must have been created to handle the I/O tasks. Right?

2. How did the evented server handled the I/O? Let's say that the I/O was to read from a database. I suspect that the web server had to create a thread to hand off the job of connecting to the database? Right?

3. If the event-driven web server indeed created threads to handle the I/O where is the gain?

4. A possible explanation for my confusion could be that on both scenarios, traditional and event-driven, three separate threads were indeed created to handle the I/O (not shown in the pictures) but the difference is really on the number of threads on the web server per-se, not on the I/O threads. Is that accurate?

Answer 1

The best way to picture NodeJS is like a furious squirrel (i.e. your thread) running in a wheel with an infinite number of pigeons (your I/O) available to pass messages around.

I/O in node is "free". Your squirrel works to set up the connection and send the pigeon off, then can go on to do other things while the pigeon retrieves the data, only dealing with the data when the pigeon returns.

If you write bad code, you can end up having the squirrel waiting for each pigeon.

So always write non-blocking i/o code.

If you can encourage your Pigeons to promise to come back ;)

Promises and generators are probably the best approach you can take to this.

HOWEVER you can always use Node cluster to establish a master squirrel that will procreate child squirrels based on the number of CPUs the master squirrel can find to dole out the work.

Hope this helps and note the complete lack of a car analogy.

Answer 2

1. Node may use threads for IO. The JS code runs in a single thread, but all the IO requests are running in parallel threads. If you want some JS code to run in parallel threads, use thread-a-gogo or some other packages out there which mitigate that behaviour.

2. Same as 1., threads are created by Node for IO operations.

3. You don't have to handle threading, unless you want to. Easier to develop. At least that's my point of view.

4. A node application can be coded to run like another web server. Typically, JS code runs in a single thread, but there are ways to make it behave differently.

Personally, I recommend threads-a-gogo (the package name isn't that revealing, but it is easy to use) if you want to experiment with threads. It's faster. Node also supports multiple processes, you may run a completely separate process if you also want to try that out.