Even though Node.js already implemented "hidden" threads using the libuv library and its thread pools for asynchronous tasks like I/O operations: File System management, TCP/UDP network requests, etc., they are still hidden from being used in a custom manner. Thus, we cannot use them to offload CPU-intensive synchronous tasks such as complex calculations, image resizing, or video compression.

In recent years, we have not seen massive improvements in the speed of CPUs. Instead, we have seen an increase in the number of cores in CPUs and have contemplated that as the upgrade in CPUs. Thus, if our code is not using the cores and logical cores of the CPUs of our hardware, cloud instances, etc. effectively, we are bound to suffer performance bottlenecks and bigger bills of underutilized instances at the end of the day.

Thus, given the cards we're dealt with, the best way of improving performance is to maximize the utilization of logical cores of CPUs using Node.js' worker-threads module and another module called workerpool .

Earlier, Node.js used Child processes (since V0.10) and Clustering (LTS since V4) as their alternatives for multithreading, while the recent worker-threads were introduced in V10 with LTS in V12. Child processes used each thread as a separate Node Process, and Clustering simplified these Child processes in a nutshell.

Worker threads and Workerpool

Worker threads

Worker-threads allow us to create threads and execute (generally CPU-intensive) multiple JavaScript tasks in parallel without blocking the main thread. As compared to the Child Processes, no additional node processes are created, all threads get created for one node runtime and the threads are also able to share memory with each other. However, according to the original documentation, worker-threads are useful for performing CPU-intensive JavaScript operations but not the I/O-intensive work as mentioned earlier. For that, the build-in async I/O handling of Node.js performs more efficiently than Workers.

Workerpool

As per the official documentation, workerpool offers an easy way to create a pool of workers for both dynamically offloading computations as well as managing a pool of dedicated workers. workerpool basically implements a thread pool pattern. There is a pool of workers to execute tasks. New tasks are put in a queue. A worker executes one task at a time, and once finished, picks a new task from the queue. Workers can be accessed via a natural, promise based proxy, as if they are available straight in the main application.

Features of workerpool:

• Easy to use and small 5kB minified size

• Runs in browsers such as Chrome, Firefox, Safari, etc. and on Node.js.

• Dynamically offload functions to a worker, handle crashed workers, access workers via a proxy

• Set timeout on tasks, cancel running tasks

• and more...

Workerpool spawns as many worker threads as the logical cores (-1) in our machine or instance. Apart from quite a few important parameters, it is to be noted that the maxWorkers is the number of logical cores of CPU minus one, this is because the other cores are used for threading and the remaining core is used for our main thread so that no blocking mechanism occurs for it.

Resource: I found a great demo on how workerpool helps us in creating efficient use of threads and CPU cores, to save the redundancy, I am sharing the 10-minute video by John Jardin below:

https://www.youtube.com/watch?v=W0go0ve1XE0

The tutorial tells us more about Child Processes, Clusters, Worker Threads, and how to do load testing using autocannon where in an encryption demo there is an improvement of 500% increase in Average requests per second! 🤯🤯

Here's the Github link for the module, where another example of a Fibonacci series is also demonstrated: https://github.com/josdejong/workerpool

P.S.: I believe this blog can be further improvised in content clarity and elaboration, I'll try to work on it soon!