CODEWITHSUNDEEP
javascriptnode.jsparallel-processingpromise
jbrtrnd
jbrtrnd

Reputation: 3833

Promise parallelism and CPU

I need to clarify something about Node.js, Promises, CPU and performance.

To set up a context, I will talk about an asynchronous processing (database query) executed multiple times (in a loop) and then do something else only after all async. processings are done.

Let's start with a code example :

async function databaseQuery() {
    return await connection.query('SELECT * FROM example;');
}

I want to perform n times an async call (databaseQuery function), and when these n executions are over, do something else.

Let's use parallels Promises to achieve this goal :

const array = [...]; // Assuming this array is full of whatever

const promises = array.map(async (item) => {
    return await databaseQuery();
});

await Promise.all(promise);

// Ok now I'm sure all async calls are done

I tried an implemention of this code in two environnements :

Obviously, performance on the local machine are far away better than on the remote one (< 1 second vs. > 1 minute).

But I need some precisions on Why ?. I'm aware that physical materials are way better on the local machine.

Moreover, as Node.js is running on a single thread on a single core why the Windows resources monitor the Node.js process using 10 threads and 6 processors ?

enter image description here

There is no "multi-processing" code implemented in the code (using cluster for example).

If I want to put this code in production, should I pay attention of the processor number of cores, or it is a Windows internal process management ?

Please help me clarify this situation, I really want to understand how does this work in the background, as it will help to choose right configuration to run this type of code.

Upvotes: 5

Views: 2866

Answers (1)

snek
snek

Reputation: 2161

Node.js runs the JavaScript you put into it in a single thread, but it has many more threads performing various tasks for I/O and the microtask queue. At the time of me writing this answer, Node.js will always have at least 7 threads: 4 for the libuv event loop[1], 4 for running background tasks for V8[2], and 1 for scheduling delayed background tasks for V8.

Your DB library, other addons, or misc things in Node.js core may be creating additional threads for various reasons.

This shows up as multi-core utilization because (in simplified terms) CPUs will pass threads around cores.

As a side note, return await is completely unneeded, you can return promises from async functions and they will be unwrapped because promise resolution is a flat-map operation.

[1] libuv handles I/O, for example reading from files, making tcp sockets, and scheduling timers.

[2] V8 background tasks include running the garbage collector and optimizing code.

Upvotes: 8

Related Questions