背景
最近在优化一个Node.js后端服务时，我决定对多进程模式进行一次真实压力测试。大家都知道Node.js是单线程模型，通常我们会用PM2的Cluster模式来启动多进程，试图榨干多核CPU的性能。理论上，这应该能让服务性能起飞，但事实真的如此吗？
测试设计
但我决定不做假设，而是用真实数据说话。我设计了一个压力测试对比：
- 单进程模式：一个 Node.js 实例运行在主核上
- 多进程模式：两个进程分别运行在两个核心上（通过 PM2 启动）
测试环境为：
- 机器：2核2G服务器
- Node.js 版本：24+
- 测试工具：autocannon
- 测试条件：10秒内发送100个并发请求
测试结果
单核心接口压力测试开始，10秒钟请求100次接口
autocannon -c 100 -d 10 http://your-server-ip:3000/api/endpoint
结果让人惊喜：平均延迟354ms哈哈哈，QPS达到278.11，数据传输量543 kB/s。表现....
多进程压测：搓手期待性能起飞，接下来配置PM2多进程模式，创建ecosystem.config.js：
module.exports = {
apps: [
{ name: "my-node-api",
script: "/var/www/my-node-api/index.js",
instances: 2, // 明确指定2个实例（或者max）
exec_mode: "cluster", //cluster-多线程模式 fork-单线程模式
env: {
NODE_ENV: "production", PORT: 3000
},
error_file: "/var/www/my-node-api/logs/err.log",
out_file: "/var/www/my-node-api/logs/out.log",
time: true,
max_memory_restart: "400M"
}]
}
开启多核心后继续压力测试，结果意想不到...
满怀期待启动服务，结果...让人大跌眼镜！
性能不升反降？数据说话
对比测试数据后，我发现了一个反直觉的结果：
1. 延迟性能下降 ⚠️
| 指标 | 单进程 | 多进程 | 变化 |
|---|---|---|---|
| 平均延迟 | 354ms | 394ms | +11.4% |
| 中位数延迟 | 348ms | 390ms | +12.1% |
| 最大延迟 | 496ms | 517ms | +4.2% |
2. 吞吐量下降 ⚠️
| 指标 | 单进程 | 多进程 | 变化 |
|---|---|---|---|
| 请求/秒 | 278.11 | 249.9 | -10.2% |
| 数据传输量 | 543 kB/s | 487 kB/s | -10.3% |
3. 稳定性略有改善 ✅
- 延迟波动（标准差）：从 43.15ms 降至 41.49ms，改善 3.8%
- 吞吐波动（标准差）：大幅减少，改善 25.4%
多进程模式为什么反而更差了？
没有想到在开启多核心的之后的压力测试并没有得到提升，反而接口延迟又变高了，请求数据量也从单核的5.48M变成了双核4.87M，我反复对比了下。 理论上多进程应该更好，但实际测试结果却相反。我分析主要有以下几个原因：
- 进程间需要通信：多个进程之间需要协调工作，这部分额外工作单进程不需要做
- 切换成本高：系统在不同进程间切换比在单个进程内切换开销更大
- 内存无法共享：每个进程都有自己的内存空间，无法共享数据
- 负载均衡本身也需要资源：分配请求的工作也需要消耗计算资源
那为什么稳定性反而提升了？
虽然性能下降了，但稳定性的确略有提升。这是因为：
- 压力分散到多个进程，单个进程负担减轻
- 一个进程出问题不会影响整个服务
- 错误被控制在单个进程内
结论与建议
多进程模式不是万能的！特别是在：
- 访问量不大时
- 业务逻辑不复杂时
- 主要是处理I/O操作时（如常见的API服务）
单进程模式可能效果更好。
什么时候应该用多进程？
- 访问量非常大时
- 需要处理大量计算任务时（如图片处理、数据加密等）
- 对稳定性要求特别高时
这次测试说明：
没有最好的方案，只有最适合的方案~
