In the previous article, I wrote about how we can use clustering to improve the performance of our application. At this point, you are probably thinking that all this clustering stuff is awesome and that you can get some real performance benefit by doing just a tiny bit of work. You may also think that it is also good just to use additional children (just a whole bunch of cluster.fork() in your application) and that means your app is going to run fast. Unfortunately, that is not the case. There is usually a point of diminishing return when we start to add a bunch of children it can impact our app negatively and in some cases can be catastrophic to your application. So by increasing the number of children in your application beyond the number of actual CPU cores that you have in your computer you will have a net negative effect on the performance of your system. Clustering is great but you have to use it with care. In general, match the number of children in your cluster to either the number of physical cores or logical cores that you have.
Let's briefly see how we can also use worker threads to improve the performance of our application. When node.js process is launched, it runs
- one process: a process is a global object that we can access anywhere and has information about what is being executed.
- single thread: only one set of instructions is being executed at a time check out my previous article on threads here.
- one event loop: the event loop is where all the application codes inside a callback function are executed. check out my previous article on the event loop here.
- one Node.js instance: The computer program that executes node.js code.
If you have a CPU-intensive code, it will block other processes from being executed. The main goal of worker threads is to improve the performance of CPU-intensive operations.
Using the diagram above, I will explain how this works. At the top is the event loop and on the bottom is the thread which will be created by this new worker object that is created by the webworker threads so this is a separate thread that is also running on our computer and because is in a separate thread, it can do a lot of CPU-intensive task such as heavy calculations and not necessary block any code that is being executed inside of our event loop. please note that we cannot freely reference variables inside of the worker from our app we have to do find some means of communication using the postMessage & onMessage. The worker interface represents the worker object that we are going to create inside of our server. The worker interface then creates the worker and we communicate back and forth between the two by using postMessage and onMessage. onMessage is a property that we can assign a function and that function is going to be invoked anytime we call postMessage on the opposing side.
You can check through the documentation to get more details about webworker threads here.