直接压测对比不同 worker_processes 配置下的 qps、延迟和错误率可验证实际影响；压测前须确保 ulimit -n ≥ worker_processes×worker_connections、/etc/security/limits.conf 设置合理、events 块启用 epoll；分三阶段压测：基线（worker_processes 1）、横向（2/4/8）、拐点（并发递增至10k）；关键看qps提升是否伴随p99延迟上升或sys cpu激增，避免调度开销抵消收益。
直接用压测工具对比不同 worker_processes 配置下的 QPS、延迟和错误率，就能看出实际影响。关键不是看理论连接数，而是看真实业务请求在高并发下的稳定表现。
压测前必须确认的三项基础
否则结果不可信：
- 系统文件句柄限制要足够：执行 ulimit -n，值必须 ≥ worker_processes × worker_connections；否则会出现 "Too many open files" 错误，压测直接失败
- /etc/security/limits.conf 中设好软硬限制，比如：* soft nofile 100000 和 * hard nofile 100000，改完需重新登录生效
- Nginx events 块里明确写 use epoll;（Linux 环境），并确保内核版本 ≥ 2.6
分阶段对比压测方法
不建议跳着调，按阶梯验证变化趋势：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 基线测试：先设 worker_processes 1;，用 wrk 发起 500 并发，记录 QPS、p99 延迟、错误率
- 横向对比：保持 worker_connections 10240 不变，依次改为 2、4、8（对应物理核心数），同样用 500 并发压测，观察 QPS 是否线性增长、CPU sys 时间是否明显上升
- 拐点探测：固定为 CPU 核心数（如 8），逐步把并发从 1k 提到 5k、10k，重点看是否出现 "accept() failed (24: Too many open files)" 或 CPU idle 持续低于 15%
关键指标怎么看才有效
不能只盯着 QPS 数字涨没涨：
- QPS 上升但 p99 延迟翻倍 → 实际体验变差，说明进程增多反而加剧争抢
- worker_processes 从 4 到 8，QPS 只涨 3%，而 sys CPU 使用率升了 25% → 多余进程带来调度开销，不值得
- 启用 worker_cpu_affinity auto; 后，各 CPU 核心负载更均匀（用 htop 观察），且延迟下降 → 说明亲和性起效，应保留
推荐的最小可行对比配置
适合大多数中等规模服务的快速验证组合：
- 测试组 A：worker_processes 1; + worker_connections 4096;
- 测试组 B：worker_processes auto;（自动匹配物理核）+ worker_connections 4096; + worker_cpu_affinity auto;
- 压测命令示例：wrk -c 1000 -t 4 -d 30s http://your-domain.com/
