Process managers like PM2 and Strongloop PM start multiple instances of your app, each of which runs a single thread. By default, they start a number of instances equal to the number of CPU cores.
If any of the instances crash, the process manager will restart them.
You can run an NGINX instance as well to load balance between multiple instances running on a single machine or across multiple machines as well. This is only needed in production. You can run your dev instance with just PM2 or Strongloop directly if you need to test performance. You usually only need to run one instance for most dev work though, which means you can just run node directly.
There is also the node "cluster" module, which you can use directly in your node server code to run multiple instances of your app. I haven't used this recently, but there were some performance issues with it before. Not sure if this has been improved.
Node also supports manually firing up threads for whatever purpose you may have. This is often used to create worker threads for any long-running CPU-intensive tasks. The main node thread and the worker thread can communicate, if necessary, using IPC.
It is very important in node to avoid blocking the main thread since no other requests can be handled in that node instance until the work is complete. Worker threads are a good option here.
Thanks for the links @n-stefan. Good to know they are using clustering.
I still think something is not optimally configured in the node case though. I could believe a 2-3 times improvement, but 8 times still makes me very suspicious. Benchmark results are notorious for being sketchy or having one configuration optimal and another sub-optimal.
It would be interesting to see the number of requests that each node instance handled to make sure the distribution is fair. The fact that there were 89 errors makes me think that perhaps the distribution was not even, and so some requests errored out.
It would also be interesting to set cluster.schedulingPolicy = cluster.SCHED_RR; mode to see if that helps.
A comparison against PM2 or StrongLoop would also be good to see (might try this out if I have some time in the next few weeks).
You could open a PR, if it's good, they will probably accept it. I'm also interested in having Node.js (and all others for that matter) run at its (their) true potential, unhindered by bad configuration and the like.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Process managers like PM2 and Strongloop PM start multiple instances of your app, each of which runs a single thread. By default, they start a number of instances equal to the number of CPU cores.
If any of the instances crash, the process manager will restart them.
strong-pm.io/getting-started/
pm2.keymetrics.io/docs/usage/quick...
You can run an NGINX instance as well to load balance between multiple instances running on a single machine or across multiple machines as well. This is only needed in production. You can run your dev instance with just PM2 or Strongloop directly if you need to test performance. You usually only need to run one instance for most dev work though, which means you can just run node directly.
There is also the node "cluster" module, which you can use directly in your node server code to run multiple instances of your app. I haven't used this recently, but there were some performance issues with it before. Not sure if this has been improved.
medium.com/skyshidigital/6-tricks-...
Node also supports manually firing up threads for whatever purpose you may have. This is often used to create worker threads for any long-running CPU-intensive tasks. The main node thread and the worker thread can communicate, if necessary, using IPC.
It is very important in node to avoid blocking the main thread since no other requests can be handled in that node instance until the work is complete. Worker threads are a good option here.
They are not wrong.
Server config: 14 physical cores, 28 logical cores (HT), 32 GB RAM.
techempower.com/benchmarks/#sectio...
The Node.js plaintext code is running as a cluster of 28 processes.
github.com/TechEmpower/FrameworkBe...
So yes, ASP.NET Core really is that much faster, time to wake up.
Excellent information Ken. Looks like I have some major 2020 studying to do.
Thanks for the links @n-stefan. Good to know they are using clustering.
I still think something is not optimally configured in the node case though. I could believe a 2-3 times improvement, but 8 times still makes me very suspicious. Benchmark results are notorious for being sketchy or having one configuration optimal and another sub-optimal.
It would be interesting to see the number of requests that each node instance handled to make sure the distribution is fair. The fact that there were 89 errors makes me think that perhaps the distribution was not even, and so some requests errored out.
It would also be interesting to set
cluster.schedulingPolicy = cluster.SCHED_RR;mode to see if that helps.A comparison against PM2 or StrongLoop would also be good to see (might try this out if I have some time in the next few weeks).
The difference is smaller in the 5 other tests.
You could open a PR, if it's good, they will probably accept it. I'm also interested in having Node.js (and all others for that matter) run at its (their) true potential, unhindered by bad configuration and the like.