CODEWITHSUNDEEP
node.js
Eastern Monk
Eastern Monk

Reputation: 6635

What exactly are the implications of the fact that nodejs is single threaded?

The NodeJS website says the following. Emphasis is mine.

Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

Even though I love NodeJS I dont see why it is better for scalable applications compared to the existing technologies such as Python, Java or even PHP.

As I understand the JavaScript run-time always runs as a single thread in the CPU. The IO however probably uses underlying kernel methods which might rely on the thread pools provided by the kernel.

So the real questions that need to be answered are:

  1. Because all JS code will run in a single thread NodeJS is unsuitable for applications where there is less IO and lots of computation ?
  2. If I am writing a web application using nodejs and there are 100 open connections each performing a pure computation requiring 100ms, at least one of them will take 10s to finish ?
  3. If your machine has 10 cores but if you are running just one nodeJS instance your other 9 CPUs are sitting ducks ?

I would appreciate if you also post how other technologies perform viz a viz NodeJS in these cases.

Upvotes: 2

Views: 514

Answers (2)

generalhenry
generalhenry

Reputation: 17319

Node.js is single threaded. This means anything that would block the main thread needs to be done outside the main thread.

In practice this just means using callbacks for heavy computations the same way you use callbacks for I/O.

For instace here's the API for node bcrypt

var bcrypt = require('bcrypt');
bcrypt.genSalt(10, function(err, salt) {
    bcrypt.hash("B4c0/\/", salt, function(err, hash) {
        // Store hash in your password DB.
    });
});

Which Mozilla Persona uses in production. See their code here.

Upvotes: 1

Alex Wayne
Alex Wayne

Reputation: 186984

I haven't done a ton of node, but I have some opinions on this. Please correct if I am mistaken, SO.

Because all JS code will run in a single thread NodeJS is unsuitable for applications where there is less IO and lots of computation ?

Yeah. Single threaded means if you are crunching lots of data hard in your JS code, you are blocking everything else. And that sucks. But this isn't typical for most web applications.

If I am writing a web application using nodejs and there are 100 open connections each performing a pure computation requiring 100ms, at least one of them will take 10s to finish?

Yep. 10 seconds of CPU time.

If your machine has 10 cores but if you are running just one nodeJS instance your other 9 CPUs are sitting ducks?

That I'm not sure about. The V8 engine might have some optimizations in it that take advantage of multiple cores, transparent to the programmer. But I doubt it.

The thing is, most of the time a web application isn't calculating. If your app is engineered well, a single request can be responded to very quickly. And if you have to fetch things to do that (db, files, remote services) you shouldn't have to wait for that fetch to return before processing the next request.

So you may have many requests in various stages at the same time in various stages of completion, due to when I/O callbacks happen. Even though only one request is running JS code at a time, that code should do what it needs to do very quickly, exit the run loop, and await the next event callback.

If your JS can't run quickly, then this model does pose a problem. As you note, things will get hung as the CPU churns. So don't build a node web application that does lots of intense calculation on the fly.

However, you can refactor things to be asynchronous instead. Maybe you have a standalone node script that can do the calculation for you, with a callback when it's done. Your web application can then boot up that script as a child process, tell it do stuff, and provide a callback to run when it's done. You now have sort of faked threads, in a round about way.

In virtually all web application technologies, you do not want to be doing complex and intense calculation on the fly. Even with proper threading, it's a losing battle. Instead you have to strategize. Do the calculations in the background, or at regular intervals on a cron job, outside of the main web application process itself.

The things you point out are flaws in theory, but in practice it really only becomes an issue if you aren't doing it right.

Upvotes: 4

Related Questions