Nginx worker进程数最优值必须通过压测确定，而非理论公式；应以响应延迟、QPS和CPU用户态使用率（%us）为核心指标，分阶段调整并观察拐点，结合worker_cpu_affinity绑核与系统资源限制验证。
直接通过压测找最优值，比查文档或套公式更可靠。Nginx 的 worker 数量是否合理，最终得看真实请求下的响应延迟、吞吐量和 CPU 利用率——这些没法靠理论推导，必须实测。
明确测试目标与关键指标
不要只盯着“QPS 越高越好”。需同步观察三项核心指标：
- 平均响应时间（Latency）：超过 50ms 或抖动明显增大，说明 worker 负载已逼近瓶颈
- 每秒请求数（QPS）：持续上升后出现平台期甚至下降，即达到当前配置的吞吐上限
- CPU 用户态使用率（%us）：top 中长期高于 85% 且 %wa 很低，说明是 CPU 瓶颈；若 %us 不高但 QPS 卡住，可能是 I/O 或连接数限制
分阶段压测：从基准到极限
每次只调一个变量（worker_processes），其余保持一致（如 worker_connections=4096、use epoll、multi_accept on），并确保系统 ulimit -n ≥ worker_processes × worker_connections × 1.5：
- 先设为物理核心数（例如 8 核 → worker_processes 8），跑 3 分钟 wrk -t4 -c2000 -d180 http://localhost/
- 再分别试 4、6、10、12，每组重复 2–3 次取中位数，避免单次抖动干扰
- 对长连接场景（如 WebSocket），改用 wrk -H "Connection: upgrade" --latency 并关注内存与 fd 消耗
识别典型拐点信号
不是数值越大越好，要盯住性能曲线转折处：
- QPS 增幅突然收窄（比如从 +12% 降到 +2%），往往就是收益衰减起点
- 延迟 P95 跳升 30% 以上，同时 %us 未达 80%，大概率是锁竞争或上下文切换开销激增
- ps aux 查看 nginx worker 进程的 %CPU 列：若多个进程长期在 100% 和 0% 之间剧烈跳变，说明调度不均，需配合 worker_cpu_affinity 绑核
配套验证与上线确认
压测结果只是参考，上线前必须做两件事：
- 用 nginx -t 校验语法，再 nginx -s reload 平滑加载新配置，禁止 kill -9 后手动启
- 上线后持续观察 15 分钟：用 ss -s 看 ESTAB 连接数是否稳定、dmesg | grep -i "out of memory" 排查 OOM 风险、cat /proc/sys/fs/file-nr 确认文件描述符未耗尽
