最可靠方式是控制变量、分层对比并结合服务端监控：客户端与Nginx物理分离，统一1KB静态资源，关闭无关进程、禁用swap、提升文件描述符至65535，局域网测试，每次压测前重启Nginx并清空page cache。
直接对比调优前后的压测数据，是验证 Nginx 调优是否有效的最可靠方式。关键不是“跑一次命令”，而是控制变量、分层对比、结合服务端监控看真实影响。
确保测试环境一致且隔离
调优效果容易被干扰因素掩盖，必须先锁定基础条件：
- 客户端与 Nginx 服务器物理分离，不能在同一台机器上运行 wrk 和 nginx；
- 测试用静态资源统一（例如一个 1KB 的 index.html），避免后端逻辑或磁盘 IO 波动干扰；
- 关闭无关进程（如数据库、监控 agent），禁用 swap，提升文件描述符限制至 65535；
- 网络走千兆或万兆局域网，排除带宽和延迟干扰；
- 每次测试前重启 Nginx，并清空系统 page cache（
echo 3 > /proc/sys/vm/drop_caches）。
用 ab 快速建立基线，验证基础吞吐变化
ab 适合做“前后快照对比”，尤其在调优初期快速判断 worker_processes、worker_connections 等参数是否起效：
- 执行相同命令两次：比如
ab -n 10000 -c 500 http://127.0.0.1/； - 重点对比三项输出：Requests per second（QPS）、Time per request（平均延时）、Failed requests（失败数）；
- 若 QPS 提升明显（如从 8000→11000）、失败数归零、平均延时下降，说明连接模型或资源限制类调优已见效；
- 注意：ab 并发不要超过 2000，否则自身成为瓶颈，结果失真。
用 wrk 深度验证高并发与长尾问题
真正体现调优价值的场景，是中高并发下的稳定性与延迟分布：
- 使用带
--latency的命令，例如：wrk -t4 -c2000 -d60s --latency http://127.0.0.1/； - 对比调优前后 P50/P95/P99 延迟：P50 变化不大但 P95 下降 30%，说明减少了长尾请求，可能得益于
keepalive_timeout或内核tcp_tw_reuse优化； - 做耐力测试（如
-d1800s），观察 QPS 是否平稳、错误率是否随时间上升——这能暴露内存泄漏或连接未释放问题； - 配合 Lua 脚本模拟真实请求头或路径参数，验证反向代理类配置（如 upstream、proxy_buffer）是否生效。
必须同步监控服务端真实状态
只看 wrk/ab 输出就像只听心跳不量血压。压测时实时盯住以下指标：
-
CPU 使用率：用
htop或mpstat -P ALL 1查看各核是否均衡，单核打满说明进程数设置不合理； -
活跃连接与等待连接：访问
http://127.0.0.1:8080/nginx_status，检查Active connections和Waiting是否持续高位，判断是否受worker_connections或accept_mutex限制； -
系统连接状态：用
ss -s观察established、time-wait数量，验证内核net.ipv4.tcp_tw_reuse等参数是否降低连接堆积； -
Nginx 日志错误：关注
error.log中的accept() failed、too many open files，这是资源上限突破的直接信号。
