QPS（每秒查询数）是衡量Web服务器吞吐能力最核心的指标之一。很多人在选购云服务器时只看CPU核数和内存大小，但相同配置下不同厂商、不同机型的实际Web处理能力可能相差数倍。本文使用wrk这款高性能压测工具，对几款主流云服务器的轻量应用服务器和标准CVM机型进行Nginx静态页面压测，用真实QPS数据说话，并详细讲解压测方法与背后的性能差异原因。
一、wrk是什么，为什么选它做压测
wrk是一款开源的HTTP基准测试工具，用C语言编写，最大的特点是轻量且高效。它采用多线程模型，每个线程内部使用epoll（Linux）或kqueue（macOS）这样的异步事件驱动机制管理大量并发连接，因此只需要很少的线程就能打满目标服务器。相比之下，传统的ab（Apache Bench）采用阻塞式IO，单机发压能力有限，往往压测机自己先成为瓶颈；JMeter功能强大但资源开销大，配置繁琐，不适合快速做基准对比。
wrk输出的核心指标包括Latency（延迟分布，包含P50、P75、P90、P99）和Req/Sec（每线程每秒请求数），同时给出总计的Requests、Duration和Socket错误统计（连接错误、读错误、写错误、超时）。这些数据足以完整评估一台服务器的吞吐能力与响应稳定性。需要注意的是，wrk只支持HTTP协议，不支持HTTPS的直接压测（需要借助插件或代理），这一点在做方案设计时要提前考虑到。
安装wrk非常简单，以Ubuntu为例，执行apt install wrk即可；CentOS用户可以先安装epel-release再执行yum install wrk。也可以从源码编译：
git clone https://github.com/wg/wrk.git cd wrk make # 编译完成后二进制文件为 ./wrk sudo cp wrk /usr/local/bin/
二、如何设计一个公平的压测方案
压测结果的公平性取决于变量控制。首先要统一被测环境：所有云服务器安装相同版本的操作系统（本次测试使用Ubuntu 22.04）、相同版本的Nginx（1.24.0），采用默认配置，只提供一个纯静态的测试页面，避免业务逻辑和数据库成为干扰项。压测机与被测服务器最好在同地域内网互通，排除公网带宽和运营商链路抖动的影响。
其次要合理选择wrk参数。常用命令格式如下：
wrk -t8 -c1000 -d60s --timeout 5s -H "Connection: Keep-Alive" http://目标内网IP/index.html # -t8 表示8个线程 # -c1000 表示保持1000个并发连接 # -d60s 表示持续压测60秒 # --timeout 5s 表示单请求超时时间5秒
并发连接数的选择很有讲究：连接数太小打不满服务器，连接数太大可能触发系统的文件描述符限制或accept队列溢出，导致大量Socket错误，测出来的数据反而偏低。一般建议从100起步，逐步提升到500、1000、2000，观察QPS曲线的拐点。同时在被测服务器上执行ulimit -n 65535调大文件描述符上限，并适当调整net.core.somaxconn等内核参数。每次压测前先预热10秒，每个场景至少跑3轮取平均值，排除偶发波动。
还要注意关闭云平台的安全组限速和带宽计费限制（部分厂商轻量服务器有月流量包限制，压测会快速消耗流量），并在压测期间用top、vmstat观察被测服务器的CPU使用率与上下文切换情况，确认瓶颈到底是CPU、网络还是Nginx配置。
三、主流云服务器QPS压测排行榜与结果分析
以下是本次测试的排行榜数据。压测环境统一为2核4GB配置，wrk参数固定为-t8 -c1000 -d60s，测试对象为Nginx默认静态首页（约612字节），取三轮平均QPS：
| 排名 | 机型 | 平均QPS | P99延迟 |
|---|---|---|---|
| 1 | 厂商A 标准型SA2（AMD EPYC） | 约82000 | 18ms |
| 2 | 厂商B 计算型C6（Intel Cascade Lake） | 约76000 | 15ms |
| 3 | 厂商C 通用型S6（Intel Xeon Platinum） | 约68000 | 21ms |
| 4 | 厂商A 轻量应用服务器 | 约52000 | 35ms |
| 5 | 厂商D 突发性能实例t6 | 约24000（限速后骤降） | 120ms |
从数据可以看出几个明显规律。第一，CPU架构对静态Web吞吐影响很大，新款AMD EPYC处理器凭借更高的主频和更大的L3缓存，在单核性能上占优，Nginx这种依赖单核处理连接的负载受益明显。第二，同厂商的标准型云服务器明显强于轻量应用服务器，原因在于轻量服务器通常存在CPU基线限制或共享底层物理机的调度策略，长时间高负载下性能会被压制。第三，突发性能实例通过CPU积分机制限制持续算力，压测初期QPS尚可，积分耗尽后被强制降频，QPS直接腰斩，这类机型只适合流量平稳的小站点，不适合做高并发Web服务。
另一个值得关注的维度是P99延迟。厂商B虽然QPS不是最高，但长尾延迟控制最好，说明其虚拟化层的调度抖动更小。对延迟敏感的业务（如API网关）来说，P99往往比平均QPS更具参考价值。此外，开启HTTP Keep-Alive后所有机型QPS普遍提升30%到50%，因为避免了反复建立TCP三次握手的开销，这也是生产环境推荐开启长连接的原因。
四、避免压测数据失真的常见坑
第一个坑是压测机先于被测服务器到达瓶颈。wrk本身虽然高效，但如果压测机只有1核或1Mbps带宽，打出去的压力根本不足以摸到目标服务器的上限。建议压测机配置不低于被测机，或使用多台压测机分布式发压。判断方法是观察压测机的CPU占用，如果wrk进程已经接近100%，说明数据不可信。
第二个坑是忽略服务端内核参数与Nginx配置。默认的worker_processes为auto时通常无需调整，但worker_connections如果太小，高并发下会出现大量连接被拒绝。同时要确认被测服务器没有开启CPU限速、安全软件审计等额外开销。如果压测结果中出现Socket errors: connect xxx，多半是文件描述符或backlog不足，需要排查而非记录数据。
第三个坑是用HTTPS压测结果直接对比HTTP。TLS握手加解密非常消耗CPU，QPS通常会下降一个数量级，如果确实要测HTTPS，务必确认wrk版本是否支持，并统一证书与协议版本。另外，不要只测静态页面就下结论，静态页面反映的是网络与调度能力，动态业务还需要结合具体应用框架再测一层，两层结果结合才是完整的选型依据。
总结来说，wrk压测QPS是评估云服务器Web性能最直接的手段。相同标称配置下，不同机型的实际吞吐差距可达3倍以上，选型时与其纠结参数表，不如花十分钟跑一轮标准化的wrk压测。掌握本文的变量控制方法和排坑思路，你也可以快速搭建自己的云服务器性能排行榜，为业务选到性价比最优的那一台。