wrk 压测 QPS 卡在 3000 是客户端先成瓶颈

现场是这样的。阿里云 ecs.c7.4xlarge 八核十六 G 上跑 Go 服务，本机 wrk 压测 QPS 一直卡在三千，服务端 CPU 只用了三成，把 wrk 线程从四调到十六也没变化。

中间走过弯路，把「响应体偏大，客户端先卡在收包而不是服务端处理」当成主因，改完现象没变。

这类报错背后常见的原因有几处，逐个排除就行。压测客户端和被压服务在同一台机器上，抢同一份 CPU 和网络栈；wrk 的连接数受进程句柄上限限制，开不到设定的并发；压测机网卡是千兆，跑到上限就平了，跟服务端无关。

第一件事是看压测期间两端各自的 CPU 占用

pidstat -u 1 10 && top -H -p $(pgrep -f wrk) | head -20

抬高句柄和临时端口范围

ulimit -n 65535 && sysctl -w net.ipv4.ip_local_port_range='1024 65535'

然后把压测端换到另一台同可用区机器

wrk -t8 -c800 -d60s --latency http://10.0.1.12:8080/api/ping

复测并对比服务端水位与 QPS 曲线

pidstat -u 1 10 | tail -5

别只看报错消失，验证要多做一步。换机后 QPS 抬到九千以上，服务端 CPU 才到七成，客户端不再打满，延迟分布的方差也明显收窄。

这里还有个坑。压测端要和被测服务分机部署，否则测出来的永远是客户端天花板；每轮压测前把两端重启一遍，清掉上一轮的连接残留。报错文案容易误导，真正的原因往往在相邻那一层的日志里。