使用Nginx搭配wrk做HTTP层基准测试，是评估Web服务吞吐与延迟特性的常见做法。wrk输出中的各项数据并非孤立存在，只有把它们和Nginx的worker模型、系统网络栈以及CPU调度联系起来，才能判断性能瓶颈到底出在哪里。很多团队跑完脚本只截图Requests/sec，却忽略了错误率和延迟分布，导致上线后在高并发下出现诡异的超时。
wrk输出核心字段的技术含义
wrk在测试结束时会打印若干关键块，其中最直观的是Requests/sec，表示每秒成功完成的请求数，它反映了Nginx在当前并发模型下的宏观吞吐能力。但这一数值高度依赖测试机的CPU核心数与网络带宽，若压测机本身只有两核，而Nginx服务端有十六核，那么Requests/sec很可能在压测端先到达上限，而非服务端先瓶颈。
另一组必须关注的是Latency区间，wrk会给出平均值以及p50、p90、p99等分位值。平均值容易被少量极快请求拉低，而p99延迟才真正代表最差百分之一的用户体验。在Nginx场景中，如果p99随并发数上升而陡增，但p50变化不大，通常说明某些请求被worker抢占或陷入阻塞调用，例如错误的DNS解析配置导致resolver超时。
Socket errors字段细分为connect、read、write、timeout四类错误。connect错误多发于Nginx的listen队列溢出，也就是backlog不足或worker_connections耗尽；timeout则往往指向后端代理缓慢或keepalive设置不当。这些错误在轻度压测中为零，却在峰值出现，正是容量规划的重要信号。
Nginx配置对基准数据的直接影响
Nginx的worker_processes通常建议设为CPU核心数，而worker_connections控制单worker可同时维持的连接数。在wrk使用keepalive模式压测时，若worker_connections偏小，新连接会被放进监听队列，一旦队列满就产生connect错误。可通过提升worker_connections并配合系统somaxconn来观察错误率是否下降。
事件模型方面，Linux下应使用epoll，FreeBSD用kqueue。若错误配置为select或poll，wrk并发稍高就会让Nginx主线程陷入忙轮询，表现为Requests/sec上不去且CPU syscpu占比极高。以下配置片段展示了生产环境常见的优化写法：
worker_processes auto;
worker_rlimit_nofile 65535;
events {
use epoll;
worker_connections 10240;
multi_accept on;
}
http {
keepalive_timeout 65;
upstream backend {
server 127.0.0.1:8080;
keepalive 32;
}
}
上述配置中multi_accept让一个worker在一次事件循环尽量多收连接，keepalive与upstream的keepalive配合能大幅减少wrk短连接测试中的握手开销。若去掉upstream keepalive，wrk的p99延迟通常会因为后端TCP重建而明显变高。
另外，access_log在高压下会成为磁盘IO瓶颈，建议压测时临时关闭或改为异步buffer。不少人发现关掉access_log后Requests/sec涨了三成，这并不代表业务代码变快，只是Nginx不再被同步写日志拖慢，解读数据时要标注此变量。
从测试结果推导调优路径的实操方法
面对一份Nginx+wrk报告，第一步应确认压测机是否成为瓶颈。观察压测机自身top中的CPU利用率，若已接近100%而服务端空闲，那么所有吞吐数字都只是压测端能力，需换更强压测机或分布式wrk。只有在压测端有余量时，服务端的Requests/sec才有参考意义。
第二步做梯度并发实验：用wrk的-c参数从64、256、1024逐步提升，记录每档的p99与错误数。若发现某临界点后吞吐持平且错误骤增，登录Nginx机器用ss -lnt查看recv-q是否堆积，再用nginx -T确认生效配置。此时若recv-q持续非零，说明应用层消费慢，应查后端或加worker。
第三步结合系统层指标，如通过cat /proc/net/softnet_stat看网卡软中断是否均衡。多队列网卡未绑核时，wrk流量可能全落在一个CPU，造成Nginx单worker热点。下面这段脚本可快速观察各CPU的软中断分布：
for i in /proc/irq/*/smp_affinity_list; do
echo -n "$i: ";
cat $i;
done
当确认中断集中后，可用irqbalance或手动绑核分散负载，再跑一轮wrk对比p99。若延迟曲线变平缓，说明之前的瓶颈在中断调度而非Nginx本身。这种由数据指向系统层再回到Nginx验证的闭环，才是基准测试真正的价值。
最后要注意测试环境的变量控制。云服务器邻居噪声、内核版本差异都会让同份配置两次wrk结果浮动百分之十几。建议在简介中记录内核版本、Nginx版本与网卡型号，把基准结果当作趋势参考而非绝对值，避免误读导致过度调参。