Node.js的cluster模块未达预期效果，压测ETIMEDOUT错误数无变化

问题核心原因 #

cluster模块的作用是解决Node.js单线程无法利用多核CPU的问题，仅在服务端逻辑存在大量CPU密集计算时才能体现性能提升，你当前的场景下瓶颈并不在CPU算力上，因此开启cluster不会改变超时错误数量，具体原因如下：

• 业务逻辑无CPU消耗：你的测试接口仅返回简单JSON响应，无任何计算开销，单进程就足以处理当前压测量级的请求，多核优势完全无法体现。
• 瓶颈为TCP连接队列溢出：所有cluster子进程共享同一监听端口的内核TCP连接队列，app.listen()默认的backlog队列长度仅为511，压测瞬间涌入的3万请求直接打满内核队列，超出队列的连接直接被丢弃触发ETIMEDOUT错误，该层面的限制和进程数量无关。
• 压测端资源限制：ETIMEDOUT也可能来自压测客户端本身：你运行Artillery的机器可能存在端口占用上限、文件描述符限制，导致部分请求无法正常发出就超时，这类错误和服务端配置无关。

验证与修复方案 #

1. 调整服务端监听配置，放大backlog队列长度：

app.listen(1337, '0.0.0.0', 4096, () => console.log('server is running on port 1337'));

2. 调整操作系统内核参数，放大全局TCP连接队列限制：将/proc/sys/net/core/somaxconn的值调整为大于等于你设置的backlog数值。
3. 放开系统文件描述符限制，执行ulimit -n 65535后再启动服务和压测工具。
4. 若要验证cluster的性能优势，可以在接口中加入CPU密集逻辑（比如大量循环计算）后再对比压测结果，此时就能看到多核带来的QPS提升和错误率下降。

内容的提问来源于stack exchange，提问作者Chaim Friedman