Despite being single threaded, how is node.js is faster? I haven't run any tests to find statistics, but while digging in the node.js forums, I find everyone says it's faster and more lightweight. But no matter how light weight it is, how can a single threaded server be faster than multi thread ones?
-
11Faster compared to what ??? – Laurent B Jun 04 '15 at 08:21
-
1@LaurentB it's definitely faster on the server than in the browser ... – Glorfindel Jun 04 '15 at 08:24
-
I hv another confusion @DenysSéguret. Node works like, it initiates some IO and assign a callback. Now once the OS finishes the process, who invokes the callback? Is it the event loop again? If yes, than won't it be a blunder for the event loop to manage those hundreads of thousands of callback? Why the event loop is not multi threaded? – Paul Shan Jun 05 '15 at 19:32
3 Answers
First, why is a program faster when multi-threaded ?
It's partly due to the fact a multi-threaded program can run on multiple cores but the main reason, by far, is that when a thread is waiting for some IO operation (which is very often, especially in a server), the other threads can still progress.
Now, what about node ?
Node isn't single threaded. The user script in JS is executed in one thread but all IO operations are natively handled by libuv and the OS which are multi-threaded.
In practice, this means that several requests are handled in parallel. Here's a very (very) simplified example of a possible sequence of actions:
user script | node + OS "threads" (libuv)
-------------------------------------------------------------
receive and analyze request 1 |
ask node for file 1 | fetching file 1
receive and analyze request 2 | fetching file 1
ask node for file 2 | fetching file 1, fetching file 2
prepare response header 1 | fetching file 2
tell node to send file 1 | send file 1, fetching file 2
prepare response header 2 | send file 1
tell node to send file 2 | send file 1, send file 2
The whole architecture of node (and io.js) makes it simple to have a high level of parallelism. The user thread is only called by the event loop for very short tasks which stop at the next IO operation (well, not really only IO, but most often) when your code gives to node a callback that will be called when the operation finished.
Of course this only works when you're using the asynchronous functions of Node. Any time you use a function ending in "Sync" like writeFileSync, you're defeating the concurrency.

- 372,613
- 87
- 782
- 758
-
Read also [StrongLoop: Why makes node faster than Java](https://strongloop.com/strongblog/node-js-is-faster-than-java/) – Denys Séguret Jun 04 '15 at 08:39
-
Node.js is not single threaded : see https://nodejs.org/about/ :
any connections can be handled concurrently
In fact, it does not use system threads, but instead uses the V8 engine along with the libuv library for multi-threading through asynchronous callbacks.
Also, you can use additional child process through child_process.fork
Finally, this does not in any way condition speed of the response or overall speed of the engine. Multi-threading is here for scalability.

- 2,200
- 19
- 29
Because nodejs won't wait for the response, instead it follows event-driven programming with callbacks i.e Once a request is submitted it will be pushed in an event queue and each request is handled by a single thread but this thread will just submit the request and move to the next request and so on and never waits for the response. Once the request is processed the respective callback function of the request will be executed.

- 134
- 5