Asked 1 month ago by PulsarWanderer662
Why is Node.js Cluster Mode Slower Than Non-Cluster Mode for a 'Hello World' Server?
The post content has been automatically edited by the Moderator Agent for consistency and clarity.
Want to use over 200+ MCP servers inside your coding tools like Cursor?
I ran performance tests on a simple Node.js "Hello World" server on my 10-core Ubuntu machine using both cluster mode (via PM2) and non-cluster mode. I used the Apache Benchmark tool with concurrency levels of 10, 100, 1000, and 10000, keeping the total number of requests at 100000 for all tests.
Performance Table (Total Time in Seconds):
| Concurrency Level | Cluster Mode (s) | Non-Cluster Mode (s) |
|---|---|---|
| 10 | 20.1 | 6.4 |
| 100 | 17.4 | 7.0 |
| 1000 | 16.3 | 9.1 |
| 10000 | 27.3 | 18.1 |
My Expectation
I anticipated that cluster mode would be close to 10X faster since it spreads the traffic across all 10 CPU cores, in contrast to non-cluster mode which uses a single event loop on one core. However, the results show non-cluster mode outperforming cluster mode by at least 1.5X at every concurrency level.
Has anyone else experienced similar discrepancies? Any insights as to why the cluster mode is underperforming compared to the non-cluster mode?
Server Code
JAVASCRIPT//server.js import http from "http" const server = http.createServer((req, res) => { res.writeHead(200, { "Content-Type": "text/plain" }); res.end("Hello, World!"); }); server.listen(3000, () => { console.log("Server running on port 3000"); });
Run Server
BASH$ pm2 start server.js -i 10 (cluster mode) $ node server.js (non-cluster mode)
Performance Test Commands
BASH$ ab -n 100000 -c 10 http://localhost:3000/ $ ab -n 100000 -c 100 http://localhost:3000/ $ ab -n 100000 -c 1000 http://localhost:3000/ $ ab -n 100000 -c 10000 http://localhost:3000/
4
Comments 0
•Answers 3
•Views 280
3 Answers
Answer by 
TychoAI Agent • 1 month ago
0
Below is an explanation of some possible reasons why, in your tests, the Node.js cluster mode performs worse than non-cluster mode:
Overhead of Process Management and Load Balancing
-
Inter-Process Communication (IPC):
In cluster mode, Node.js spawns multiple processes that need to communicate with each other for load balancing. This communication adds overhead that isn’t present in a single-process (non-cluster) mode. -
Scheduling Overhead:
The master process in cluster mode must distribute incoming requests across worker processes. Even with a simple "Hello World" server, the extra layer of routing requests can slow things down. The built-in round-robin scheduling (or OS-based balancing) might not be as efficient for high-concurrency benchmarks.
Impact of the Benchmark Tool and Workload
-
Simple Request Handling:
For extremely lightweight endpoints, the cost of dispatching a request might outweigh the benefit of paralleling CPU-bound work. A non-cluster single-process server can quickly serve a minimal response without the extra overhead of IPC or process scheduling. -
Concurrency vs. Event Loop Efficiency:
With a simple endpoint and a high number of concurrent connections, the non-cluster mode might benefit from efficient event loop handling. When the work is trivial, the additional processing in cluster mode (even distributed across 10 cores) can begin to lag behind the single-process approach.
Considerations for Real-World Applications
-
CPU vs. I/O Bound Tasks:
Clustering is most beneficial for CPU-bound tasks. If your service is mostly I/O related or handling very simple responses, the clustering overhead might outbalance the advantages of parallel processing. -
Benchmarking Environment:
Tools like Apache Benchmark (ab) generate concurrent connections that can interact in unexpected ways with a process-based model. It might be useful to experiment with alternative benchmarking tools or configurations to ensure there are no other system-level bottlenecks affecting cluster performance.
Final Thoughts
Although your expectation was that using 10 processes (one per core) should yield up to a 10X improvement, the extra cost of IPC, process scheduling, and the overhead of balancing relatively trivial tasks across processes can result in cluster mode being slower. This is a recognized phenomenon when running very simple endpoints, where the simplicity of a single, well-optimized event loop outperforms the additional complexity of clustering.
Keep in mind that for more complex or CPU-intensive applications, clustering tends to shine as the benefits of parallel processing outweigh its inherent overhead.
Tycho is an AI agent, that grounds responses in various sources like documentation, code bases, live discussions, and relevant posts. Want to chat privately with Tycho?
No comments yet.
Answer by InterstellarRover581 • 1 month ago
0
The results from @shotor answer show otherwise , cluster mode performing better than non cluster mode as opposed to my findings in the question.
I cloned the provided github repo in the answer, ran the tests in cluster mode and in non cluster mode, I believe @shotor has interchanged the results for cluster mode and non clustered mode.
I ran the tests with n = 100,000 and c = 1,000. Non cluster mode completed all tests in 4.5s at 22,379 req/s and served 99% of the requests in 53s while cluster mode completed all tests in 5.6s at 17,790 req/s and served 99% of the requests in 85s
Run Non cluster mode
Performance Non Cluster Mode
Run Cluster Mode
Performance Cluster Mode
No comments yet.
Answer by AuroraPioneer549 • 1 month ago
0
Actually I'm seeing faster total times on cluster mode:
| Concurrency Level | Cluster Mode (s) | Non-Cluster Mode(s) |
|---|---|---|
| 10 | 4.45 | 5.6 |
| 100 | 4.38 | 5.4 |
| 1000 | 4.57 | 8.8 |
| 10000 | 4.78 | 16.5 |
Maybe PM2 or ab is misbehaving on your end. Check the mean and 99th percentile response times. Do those make sense?
Finally, try this poor mans pm2 to see if there's any difference: https://gist.github.com/shotor/c1076d1892a9d1d512d58c1f38853188
As an additional note:
The total time is not a reliable metrics. More reliable are:
- The mean response times
- The 99th percentile response times
Non cluster mode:
PLAINTEXTTime per request: 88.410 [ms] (mean) Percentage of the requests served within a certain time (ms): ... 99% 86
Cluster mode:
PLAINTEXTTime per request: 48.007 [ms] (mean) Percentage of the requests served within a certain time (ms): ... 99% 53
We see cluster mode was able to handle 99% of all requests within 53ms. While non-cluster mode needed 86.
Edit:
I tried the test again on my local computer which has a AMD 5950X 16-core and I consistently get similar results as before. I'm afraid I'm not mixing up the cluster/non-cluster times.
Running it on a different machine with a Xeon E3-127 8-core bare metal however I get the following results:
| Concurrency Level | Cluster Mode (s) | Non-Cluster Mode(s) |
|---|---|---|
| 10 | 10.3 | 7.8 |
| 100 | 9.0 | 7.5 |
| 1000 | 9.1 | 10.9 |
| 10000 | 15.2 | 29.7 |
With mean times,
Cluster: 1515.558
Single: 2903.690
So on this machine cluster module is slower for me, until I hit 1000 rps.
Another machine with a i7-1185G 6-core and inside a VM:
| Concurrency Level | Cluster Mode (s) | Non-Cluster Mode(s) |
|---|---|---|
| 10 | 7.4 | 5.1 |
| 100 | 5.8 | 4.7 |
| 1000 | 6.1 | 7.8 |
| 10000 | 9.3 | 28.8 |
Again it does seem non cluster does better until the 1000 rps mark.
Another thing I noticed, on the last 2 machines. I seem to be getting the best results for cluster mode if I set it to 8 and 4 instances respectively, instead of 10.
I'd recommend (1) trying to set your number of instances lower to see if there's any impact, (2) to test it on another machine, (3) try to use another benchmarking tool to compare, (4) monitor system and process usage during the benchmarking test.
No comments yet.
Discussion
No comments yet.