PM2 is very good and I really wonder why it's still somewhat unknown.
People complaining that Node.js only use one CPU core, or benchmarks with low scores for Node.js. There are solutions for this! PM2 is one of them and is very good. Use it.
People complaining that Node.js only use one CPU core, or benchmarks with low scores for Node.js. There are solutions for this! PM2 is one of them and is very good. Use it.
At work, most of our app is docker-composed in one VPS (early B2B product with few customers). I would like to have the multiple-process benefits of PM2, but I don’t want to spin up a whole load balancer for it, or split the node service from the other services. Everything is so simple right now and I’d like to keep it that way lol.
Last time I googled this I found conflicting opinions, but if I can just stuff PM2 into my node container, I’d be a happy dev!
I can see why people like pm2, similarly to why I can see why people like Nodejs. But I think pm2 is half-baked, and Nodejs's greatest design feature (single-threaded async execution) is flawed by design.
You write nodemon or npm start- and so it's put at the end of the Dockerfile as such.
I know someone that discovered pm2 because copilot autocompleted their Dockerfile that way.
Properly written node apps are bound by I/O throughput. CPU and memory cost for additional processes is minimal, but latency is significantly decreased with a worker pool.
Does that mean that node apps shouldn’t do any computation on data, just move bytes between a file and a network socket? If I need my program to think, I wrote it wrong or in the wrong language?
I would rather have shared memory multithreading be a usable feature in my program’s runtime. SharedArrayBuffer exists but 98% of existing code uses objects and arrays so can’t be easily shared between processes without copying, and the cost of copying objects with structuredClone puts a huge optimization barrier in between most code and parallel processing.
This is a very uncharitable interpretation of Node's primary use case. I think it would be more accurate to say don't use Node if all of the following apply:
- Your task is CPU bound rather than IO bound (e.g. you're not waiting to insert or retrieve data from the database).
- Your task is highly parallel (some computations are sequential and linear).
You can't use worker threads because:
- You have too much data to bear the cost of message passing via the structured clone algorithm.
- You can't share memory and avoid structured cloning because your data can't be represented using an array buffer.
This is a far cry from the claim that Node can't handle problems that require "thinking". When you're on the JIT compiler's happy path Node can think pretty quickly actually. In practice, many high volume web servers are handling enough requests that there's more than enough jobs for each Node process to have exclusivity over its jobs, and you don't need to share work between processes. Each process or worker thread can be largely independent. Not every task is going to fall within those boundaries, but that's ok, Node doesn't have to fulfill every use case.
If you need to compute something complicated, write it in a compiled language and make it a node module. Many popular npm libraries are exactly this.