云服务器性能评估离不开HTTP压测，ab和wrk是两款常用的命令行工具。虽然都能发送并发请求并统计吞吐量，但把它们的测试结果直接放在一起比较，往往会得出互相矛盾的结论。理解两者的并发模型和统计逻辑，是获得可靠压测数据的前提。

一、并发模型差异是结果悬殊的根源

ab（ApacheBench）随Apache HTTP服务器发布，最早用于测试Apache自身的静态资源处理能力。它的实现基于Apache可移植运行时（APR）库，主循环使用单线程和select/poll事件通知机制管理所有并发连接。虽然通过-c参数可以同时打开数百甚至上千个套接字，但请求的发送、响应读取和统计都由一个线程完成。当并发数增大时，客户端CPU往往先达到瓶颈，导致压测端无法向服务器施加足够压力，测得的数据不能反映服务器真实性能。

wrk则从设计之初就面向高并发压测场景，它借鉴了Redis的事件循环思路，使用多线程架构。每个工作线程独立运行一个事件循环，各自维护一批连接，通过非阻塞I/O高效地发送和接收HTTP请求。这样在多核云服务器上，wrk可以真正利用多个CPU核心，产生远高于ab的请求压力。此外，wrk默认启用HTTP Keep-Alive，连接复用减少了TCP握手和慢启动的影响，而ab需要显式加上-k参数才能达到类似效果。

因此，同样参数下，wrk的QPS往往明显高于ab，这并不代表服务器变快了，而是客户端能力不同。对于评估服务器峰值吞吐量，wrk更有参考价值；但如果只是检查服务是否存活、基础响应时间是否正常，ab的简单输出已经够用。

二、安装方式和常用参数对比

安装ab相对简单。在Debian或Ubuntu上，通过apt安装apache2-utils包即可获得ab命令；在CentOS或RHEL上，对应的软件包是httpd-tools。安装完成后无需额外配置，直接执行ab -V可以查看版本。wrk则需要从源码编译，官方仓库位于GitHub，依赖GCC、Make和OpenSSL开发库。编译过程在大部分Linux发行版上都能顺利通过，也可以使用第三方提供的静态二进制文件。

# Ubuntu/Debian 安装 ab
sudo apt update
sudo apt install apache2-utils
# CentOS/RHEL 安装 ab
sudo yum install httpd-tools
# 从源码编译安装 wrk
git clone https://github.com/wg/wrk.git
cd wrk
make
sudo cp wrk /usr/local/bin/
# 验证版本
wrk --version

ab的常用参数包括：-n指定总请求数，-c指定并发连接数，-k启用Keep-Alive，-p指定POST数据文件，-T设置Content-Type，-H添加自定义请求头。例如ab -n 10000 -c 200 -k http://ipipp.com/会模拟200个并发连接持续发送请求。需要注意的是ab的-n参数控制的是总请求数，测试时长不固定；而wrk使用-d参数直接指定持续时间，例如-d 30s表示连续压测30秒，总请求数由服务器响应速度决定。

wrk的核心参数包括：-t设置工作线程数，通常设置为核心数或核心数的两倍；-c设置总连接数；-d设置压测持续时间；-H添加请求头；--latency输出延迟分位数；-s加载Lua脚本，用于构造复杂请求。wrk的线程和连接数是分离的，总连接数会被分配到各个线程上，这种方式更灵活，也更贴近真实负载模型。

三、输出指标解读与常见误区

ab测试完成后会输出若干指标，其中最容易混淆的是两个Time per request。第一行Time per request (mean)表示从用户视角看到的平均响应时间，单位是毫秒；第二行Time per request (mean, across all concurrent requests)表示所有并发请求分摊到每个请求上的平均间隔时间，数值上等于第一行除以并发数。很多人把第二行当成响应时间，这是错误的。例如并发100时第一行为56.78ms，第二行为0.568ms，实际服务器处理每个请求平均需要56.78ms，0.568ms只是压测端的请求发出频率。

Server Software:        nginx/1.18.0
Server Hostname:        ipipp.com
Server Port:            80
Document Path:          /
Document Length:        612 bytes
Concurrency Level:      100
Time taken for tests:   5.678 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      8900000 bytes
HTML transferred:       6120000 bytes
Requests per second:    1761.23 [#/sec] (mean)
Time per request:       56.78 [ms] (mean)
Time per request:       0.568 [ms] (mean, across all concurrent requests)
Transfer rate:          1532.11 [Kbytes/sec] received

ab还提供Requests per second（吞吐量）和Transfer rate（传输速率）。需要注意的是，如果压测过程中出现Failed requests，即使只有少量失败，平均响应时间也可能被大幅拉高或拉低。ab默认不会详细列出每个请求的延迟分布，只看平均值无法发现长尾问题。例如某些请求因为数据库锁等待耗时2秒，但大多数请求在10ms内完成，平均值仍然可能在几十毫秒，掩盖了性能隐患。

wrk的输出则更注重延迟分布，使用--latency参数后可以得到50%、75%、90%、99%分位延迟。例如90%分位为15ms意味着90%的请求在15ms以内完成。这种统计方式能帮助定位慢请求比例，对容量评估至关重要。wrk还会给出Requests/sec和Transfer/sec，吞吐量数据更接近服务器极限。但wrk默认使用HTTP/1.1并开启Keep-Alive，如果服务器对长连接处理有特殊限制，测试结果可能偏离真实用户行为。

四、云服务器压测的注意事项与工具选型建议

在云服务器上使用ab或wrk时，网络拓扑会直接影响数据可信度。如果压测客户端和目标服务器不在同一个私有网络中，公网带宽、运营商线路抖动、安全组规则都可能成为瓶颈。建议将压测客户端部署在目标服务器同可用区或同VPC内的云主机上，使用内网IP进行测试，以排除外部网络干扰。同时，云服务器的突发性能实例（如t系列）有CPU积分机制，长时间高负载会消耗积分导致CPU性能下降，压测结果可能前后不一致。

对于带宽限制，如果测试静态资源下载，公网带宽规格可能先于服务器处理能力达到上限，此时看到的高延迟不代表后端性能差。可以通过逐步提高并发、观察吞吐量曲线是否趋于平缓来判断瓶颈位置。安全组和本地防火墙也可能丢弃高位端口的连接，导致连接建立失败，需要提前放通压测端口。

工具选型上，如果是简单的HTTP GET请求、快速验证服务可用性，ab足够轻量，命令简单；如果需要模拟高并发、获取精确延迟分位数、测试多核服务器极限性能，wrk是更好的选择。对于需要构造POST JSON、自定义Cookie、动态URL参数等场景，wrk的Lua脚本接口提供了更强的扩展能力，ab虽然支持-p发送POST数据，但灵活性较差。实际工作中可以先用ab做冒烟测试，再用wrk做深度压测，两者配合能更全面地评估云服务器性能。

-- post.lua
wrk.method = "POST"
wrk.body   = '{"key":"value"}'
wrk.headers["Content-Type"] = "application/json"

执行时使用wrk -t4 -c100 -d30s -s post.lua http://ipipp.com/api即可模拟JSON接口的并发请求。这种组合方式在实际云服务器压测中非常实用，既能保留wrk的高并发能力，又能覆盖ab难以实现的复杂请求场景。