wrk是一款开源的高性能HTTP基准测试工具，它利用多线程和事件驱动机制在单台压测机上模拟大量并发连接。与传统的ab相比，wrk支持Lua脚本扩展，可以构造更接近真实业务的请求；与Locust等分布式压测工具相比，wrk又足够轻量，几分钟内就能完成安装和首轮压测。因此在云服务器选购、规格对比以及上线前的容量评估中，wrk经常被用来快速得到HTTP服务的QPS参考值。
一、用wrk完成一次标准的云服务器HTTP压测
在Linux或macOS上安装wrk并不复杂。以Ubuntu为例，如果系统软件源里没有现成包，可以直接从源码编译。先安装编译依赖，再从GitHub克隆仓库并执行make，最后把生成的可执行文件复制到系统路径即可。整个过程通常只需要一两分钟，这也是很多工程师在临时压测时优先选择wrk的原因。
sudo apt update sudo apt install -y build-essential libssl-dev git git clone https://github.com/wg/wrk.git cd wrk make sudo cp wrk /usr/local/bin
安装完成后，最基本的压测命令只需要指定线程数、连接数、持续时间和目标地址。例如使用4个线程、保持100个并发连接、持续30秒，对云服务器上的Nginx首页进行压测。参数-t控制线程数，-c控制总连接数，-d控制持续时间。wrk会在时间窗口内持续发送请求，并汇总请求速率和响应延迟。
wrk -t4 -c100 -d30s --latency http://192.168.1.10/
命令结束后，输出结果里最受关注的指标是Requests/sec，也就是常说的QPS。它表示服务器每秒成功处理的请求数量。旁边的Transfer/sec反映吞吐量，而Latency部分则给出平均延迟、标准差和百分位延迟。单独看QPS很容易被静态文件或者短响应的场景放大，因此必须结合延迟分布和错误率一起评估。压测时还要确认压测机本身没有达到CPU或带宽上限，否则测出来的就不是云服务器的真实能力。
二、影响云服务器HTTP QPS排行榜的关键变量
同一台云服务器在不同的压测参数下，QPS可能相差数倍。并发数过低时，服务器资源没有被充分占用；并发数过高时，线程切换、连接队列和上下文切换开销会反过来拉低吞吐。因此一份可信的QPS排行榜必须固定线程数、连接数和持续时间，并明确标注这些参数。常见做法是先做一轮并发递增测试，找到QPS达到峰值后不再上升的饱和点，再以该并发数作为对比基准。
实例规格对结果的影响同样显著。CPU核数直接决定Nginx或业务进程能并行处理多少请求，对于计算密集型的动态接口尤其关键；内存不足会触发交换分区，导致延迟突增；而云盘IO性能会限制日志写入、Session落盘和静态文件读取。还有一个容易被忽略的变量是网络带宽。如果压测目标响应体较大，例如返回一张200KB的图片，那么QPS会迅速被带宽卡住，此时排行榜反映的其实是带宽上限而不是计算能力。
Keep-Alive开关也会改变结果。开启Keep-Alive后，客户端可以复用TCP连接，省去频繁三次握手和四次挥手的开销，Nginx通常会表现出更高的QPS。但如果后端应用存在连接泄漏或长连接占用过多资源，Keep-Alive反而可能降低稳定性。使用wrk时，默认会复用连接，若需要模拟短连接场景，可以在Lua脚本中显式设置Connection请求头为close。
三、用Lua脚本构造可对照的压测场景
如果只对首页发起GET请求，排行榜的参考价值十分有限，因为真实业务往往包含查询参数、请求头、POST提交和动态路径。wrk的Lua扩展允许在压测前定义请求方法、请求头和请求体，甚至根据计数器动态改变URL。下面这段脚本会随机轮换访问不同的文章详情页，并在每个请求中携带自定义User-Agent和Keep-Alive头，这样得到的QPS更接近实际读多写少的内容站点。
wrk.method = "GET"
wrk.headers["Connection"] = "keep-alive"
wrk.headers["User-Agent"] = "wrk-benchmark"
local counter = 0
local max_id = 5000
request = function()
counter = counter + 1
local id = counter % max_id
return wrk.format(nil, "/article?id=" .. id)
end
将此脚本保存为article.lua，在wrk命令中使用-s参数加载即可。例如wrk -t8 -c200 -d60s -s article.lua http://目标服务器/。这样所有参与排行的云服务器都会收到相同的请求序列，避免因静态首页缓存或固定URL导致的数据失真。脚本中还可以通过response函数统计状态码，或使用done函数汇总自定义指标。
在实际对比时，建议把每台云服务器的压测结果整理成表格，至少记录QPS、平均延迟、P99延迟、错误数和实例规格。表格能直观展示哪些机型只是QPS高但延迟不稳定，哪些机型在中等并发下性价比更高。如果条件允许，最好在同一地域、同一可用区、同一VPC内创建压测机和目标机，减少公网抖动对排行结果的影响。
四、从QPS排行榜看优化方向与避坑要点
拿到排行榜数据之后，如果某台服务器QPS明显低于同规格的其他实例，不要急着下结论说该云厂商性能差。先查看压测期间的目标机CPU使用率和软中断情况。使用top、vmstat或mpstat可以快速判断是否出现单核打满、多核不均衡的情况。对于Nginx这类多进程服务，调整worker_processes和worker_connections往往能带来即时提升；如果后端是PHP-FPM，还需要检查pm.max_children是否过小。
网络层也经常产生瓶颈。当QPS上升到一定水平后，Linux默认的内核参数可能不再适用。例如net.core.somaxconn控制监听队列长度，net.ipv4.tcp_max_syn_backlog影响半连接队列，net.ipv4.ip_local_port_range决定压测机可用端口数量。尤其是压测机并发连接数很高时，端口耗尽会直接中断压测，测试数据自然不准确。可以通过调大端口范围、减少TIME_WAIT等待时间来解决。
另外要警惕压测结果被缓存放大。如果应用层启用了页面缓存、CDN或Nginx的proxy_cache，压测请求可能根本没有到达后端业务逻辑，测出来的QPS反映的是缓存命中能力。排行榜中需要标注是否开启缓存，否则会误导后续容量规划。对于动态接口，建议在Lua脚本里加上随机参数强制绕过缓存，或者压测一个明确标记为no-cache的路径。
最后，单次压测时间不宜过短。30秒可能只覆盖了突发的瞬时性能，建议至少持续3到5分钟，并观察QPS曲线是否平稳。如果QPS在测试中途出现明显下降，可以记录时间点并检查日志，定位是否由GC停顿、日志刷盘或云平台资源争抢引起。只有经过多轮重复测试并取中位数，生成的云服务器QPS排行榜才有实用价值，而不是一个只能用于宣传的数字。