Nginx基准测试核心是可控施压与同步观测：ab适合快速摸底，wrk支撑高并发与长时压测；需同局域网分离客户端/服务器、清空系统缓存、优先静态资源、一次只调一个变量，并同步监控QPS、延迟（P50/P95）及CPU等指标。
实现 Nginx 进程的性能基准测试，核心是用可控方式施加真实负载，并同步观测服务端响应与系统资源状态。不能只看工具输出的 QPS，而要让每次结果可比、可归因、能指导调优。
明确目标并选对压测工具
先想清楚这次测什么：是找最大吞吐？查 CPU 是否瓶颈？还是验证某个配置（比如 worker_processes）的影响？目标不同，关注点就不同。
-
ab（Apache Bench）适合快速摸底：命令简单，例如
ab -n 10000 -c 500 http://localhost/，重点看 Requests per second 和 Time per request；但并发超过 2000 后它自身容易成瓶颈，不适合高并发场景 -
wrk是主力工具：单机支撑数千并发，支持长时压测和延迟分布统计；推荐命令如
wrk -t4 -c2000 -d180s --latency http://localhost/，加上--latency可看到 P50/P95 延迟，对发现长尾问题很关键
搭建可信的测试环境
环境不干净，结果就不可信。必须满足几个硬条件：
- 客户端和 Nginx 服务器不能在同一台机器上，否则压测工具会抢 CPU 和网络资源，干扰 Nginx 表现
- 两者必须在同局域网（最好千兆或万兆直连），排除公网抖动和带宽限制带来的误差
- 每次测试前执行
sync && echo 3 > /proc/sys/vm/drop_caches，清空页缓存、目录项缓存和 inode 缓存，避免文件系统缓存影响静态资源响应时间 - 压测对象优先用最小静态文件（如 2KB 的 index.html），排除后端逻辑、数据库等干扰因素
控制变量，分阶段实测 worker 进程数
Nginx 的 worker_processes 没有通用最优值，必须通过压测找拐点。记住：一次只调这一个参数，其余全固定（比如 worker_connections 4096、use epoll、multi_accept on）。
- 先设为物理核心数（如 8 核 →
worker_processes 8），用 wrk 跑 3 分钟基准线 - 再依次尝试 4、6、10、12，每组重复 2–3 次取中位数，避开单次抖动干扰
- 重点关注三项指标同步变化：平均延迟是否突增（P95 跳升 30%+ 是危险信号）、QPS 是否进入平台期或回落、CPU 用户态（%us）是否长期高于 85%
- 若 %us 很低但 QPS 卡住，说明瓶颈不在 CPU，可能是文件描述符不足（检查
ulimit -n ≥ worker_processes × worker_connections × 1.5）或内核连接限制
上线前必须做的两件事
压测结果只是参考，真正落地要闭环验证：
- 改完配置后，先运行
nginx -t检查语法，再用nginx -s reload平滑重载，严禁kill -9后手动启动 - 上线后盯 15 分钟真实流量：用
htop或mpstat -P ALL 1看各核负载是否均衡；用ps aux | grep nginx配合psr列确认 worker_cpu_affinity 是否生效；同时观察错误日志和连接数增长趋势
