ab 和 wrk 压测工具有什么区别？
更新时间：2026-09-19。短答页。两者都是最常用的轻量 HTTP 压测 CLI，选型主要看「并发量」和「要不要复杂请求」。
一句话回答
ab 简单、基本单线程，适合对单个 URL 快速摸底；wrk 用 epoll/kqueue 事件驱动 + 多线程，单机可以制造高得多的并发压力，且支持 Lua 脚本生成动态请求、带 header/POST，复杂场景和正式压测用 wrk。
对比
| 维度 | ab（ApacheBench） | wrk |
|---|---|---|
| 模型 | 基本是阻塞式、能力受单机线程限制 | 事件驱动（epoll），多线程 reactor |
| 单机压力 | 中低，高并发时压测机自身先成瓶颈 | 高，少量线程即可数万连接 |
| 请求构造 | 单个 URL，参数有限 | Lua 脚本：动态路径、参数、header、Cookie、POST body |
| 协议 | HTTP/1.0/1.1 | HTTP/1.1（HTTPS） |
| 上手 | 极简，几乎零学习成本 | 略多，但命令也很短 |
| 适合 | 5 分钟验证、快速看 QPS/延迟 | 正式压测、复杂场景、找拐点 |
典型命令
bash
# ab：100 并发、共 10000 请求
ab -n 10000 -c 100 http://127.0.0.1:8080/api/ping
# 长连接 + keep-alive
ab -n 100000 -c 200 -k http://127.0.0.1:8080/
# wrk：2 线程、200 连接、持续 30s
wrk -t2 -c200 -d30s --latency http://127.0.0.1:8080/api/ping
# 用 Lua 脚本发带 header/动态参数的请求
wrk -t4 -c500 -d1m -s post.lua http://127.0.0.1:8080/api/order结果怎么读
两者都给 Requests/sec（QPS）、Time per request、传输量；wrk 的 --latency 额外输出 50%/75%/90%/99% 分位延迟，做尾延迟和 SLO 评估更有用（分位意义见 P99）。看结果要结合：成功率/非 2xx 比例、延迟分位、被测端 CPU/GC/错误日志，而不是只盯 QPS。
选型与注意
- 快速冒烟、单 GET：ab 足够，随处可用。
- 高并发、找容量拐点、复杂请求：wrk，必要时用 JMeter 做带线程组/断言/报表的复杂测试计划，gRPC 用 ghz。
- 压测机自身资源要够（wrk 也可能打满客户端），跨网络要区分是被测端瓶颈还是带宽/压测机瓶颈。
- 用长连接（
-k/ wrk 默认）与短连接结果差异巨大，按真实场景选；逐步加压找 P99 拐点而非一上来满并发。
坑
- 用 ab 高并发压测，压测机单核先打满，误判服务端容量。
- 只看平均 QPS，忽略非 2xx 比例和 P99，得到「高 QPS 但大量超时」的假结果。
- 长连接压测的数字套到短连接线上流量，严重高估容量。
- 没盯被测端资源，QPS 上不去时分不清是客户端、网络还是服务端瓶颈。
总结
ab 是几乎零门槛的单 URL、偏阻塞式压测工具，适合快速验证一个接口的 QPS 和基本并发表现；wrk 基于 epoll 事件驱动和多线程、用更少资源制造更高并发，并用 Lua 支持动态参数、header 和 POST，配合 --latency 直接给出尾延迟分位，更适合正式压测和找容量拐点；两者都要同时看成功率、P99 和被测端资源，并按线上是否长连接选择压测方式、逐步加压。