震惊！多核性能反降11%？node接口压力测试出乎意料！

背景

最近在优化一个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：

vbnet 复制代码

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服务）

单进程模式可能效果更好。

什么时候应该用多进程？

访问量非常大时
需要处理大量计算任务时（如图片处理、数据加密等）
对稳定性要求特别高时

这次测试说明：

没有最好的方案，只有最适合的方案~