最可靠方法是固定环境只调worker_processes并用wrk压测：同局域网、清页缓存、纯静态资源、禁日志，监控QPS、P95/P99延迟、失败率及cs值、CPU均衡性；8核下1进程QPS≈1000，auto时QPS≈7500。
直接压测对比是最可靠的方法：固定其他所有配置和环境，只改 worker_processes，用相同工具、相同并发量、相同资源路径发起请求，看 QPS 变化。
准备可比的压测环境
确保测试结果真实反映进程数调整的影响，而不是被干扰因素掩盖：
- 压测客户端和 Nginx 服务器必须在同局域网，避免网络抖动影响延迟和成功率
- 每次测试前清空系统页缓存（
echo 3 > /proc/sys/vm/drop_caches），防止文件缓存干扰静态资源响应时间 - 统一使用纯静态资源（如一个 1KB 的
index.html），排除后端服务或 SSL 握手波动 - 禁用日志写入（
access_log off;）或写入内存盘，避免 I/O 成为瓶颈 - 一次只调一个变量——比如只从
worker_processes 1改为auto，其余参数完全不变
执行标准化压测并采集关键指标
推荐用 wrk（比 ab 更稳定、支持长时高并发），命令示例如下：
wrk -t4 -c1000 -d60s http://your-nginx-ip/index.html
其中：
-t4 表示 4 个线程（模拟客户端并发连接管理）
-c1000 表示维持 1000 个并发连接
-d60s 表示持续压测 60 秒
每次运行后记录三项核心输出：
- Requests/sec（即 QPS）——主衡量指标
- Latency Distribution 中的 P95 和 P99 延迟——判断是否因调度过载导致尾部延迟飙升
- Non-2xx or 3xx responses（失败率）——若明显上升，说明已超承载极限
同步监控系统级表现
光看 QPS 不够，要确认性能提升是否“健康”：
- 用
vmstat 1观察每秒上下文切换数（cs列）：正常应 ≤10000；若 >30000 且 QPS 下降，大概率是 worker 进程过多引发调度开销 - 用
top或htop看 CPU 各核使用是否均衡：如果只有 1–2 核跑满、其余闲置，说明worker_processes设置过低或未启用worker_cpu_affinity - 检查
ps aux | grep nginx确认实际启动的 worker 进程数与配置一致（注意 master 进程不参与处理）
典型效果参考与判断依据
以 8 核服务器为例：
-
worker_processes 1→ QPS ≈ 1000，CPU 单核 100%，其余空闲 -
worker_processes auto（即 8）→ QPS ≈ 7500，CPU 八核平均 85%，上下文切换 - 继续设为 16 或 32 → QPS 不再上升甚至略降，
cs超 25000/秒，P99 延迟翻倍
这说明当前硬件下，8 个 worker 是最优解。QPS 提升幅度就是 7500 ÷ 1000 = 7.5 倍——不是理论值，而是实测值。
