4. 压测工具选型：JMeter、Locust、wrk、ab
说到压测工具，我这些年算是把它们都折腾过一遍了。刚入门时逮着一个工具就往死里用，后来踩过不少坑才发现——选错工具，压测结果根本没法信。
今天聊聊最主流的四款：JMeter、Locust、wrk 和 ab。每个都有它的脾气。
4.1 各工具定位速览
先把几个工具的核心特点列清楚，后面我再逐个细说。
| 工具 | 语言 | 界面 | 协议支持 | 分布式 | 典型场景 |
|---|---|---|---|---|---|
| JMeter | Java | GUI + CLI | HTTP/HTTPS、JDBC、JMS、FTP 等 30+ 协议 | 自带分布式 | 复杂业务场景、多协议、企业级 |
| Locust | Python | Web 实时面板 | HTTP/HTTPS（可扩展其他协议） | 自带分布式 | 自定义场景、敏捷团队、快速验证 |
| wrk | C | 命令行 | HTTP/HTTPS | 单机多线程 | 纯 HTTP 压测、极致性能 |
| ab | C | 命令行 | HTTP/HTTPS | 单进程 | 快速验证、少量并发 |
4.2 逐个拆解
4.2.1 JMeter — 重型航空母舰
JMeter 是我用得最多的工具，没有之一。它的 GUI 界面虽然有点「老爷车」的感觉，但功能是真全。
优点：
- 支持参数化、关联、断言、监听器一条龙。
- 自带分布式压测模式，controller + agent 结构。
- 插件生态丰富，比如
jp@gc - PerfMon Metrics Collector可以直接采集服务器 CPU 内存。
缺点：
- 启动内存很大，默认 512MB，压测本身又吃资源。
- GUI 模式下跑高并发容易卡死，我建议只在调试时用图形界面，上生产压测必须转命令行。
- 脚本是 XML 格式，维护起来有点头疼。
我记得有一回线上故障排查，压测失败后去看 JMeter 的日志，发现 OOM 了——不是被测系统垮了，是 JMeter 自己先躺了。从那以后我就记住了：分布式压测时，agent 的内存得给够。
4.2.2 Locust — 轻量灵活的 Python 派
Locust 这几年越来越火。它的核心逻辑是用 Python 写用户行为，比 JMeter 的拖拽组件灵活十倍。
优点：
- 脚本即压测，Python 开发者上手零成本。
- Web 面板实时展示 RPS、响应时间、失败率，比 JMeter 的「树」视图直观。
- 协程模型，单机就能模拟几千并发。
缺点：
- 默认只支持 HTTP，要测 Dubbo、gRPC 得自己写 Client。
- 分布式模式下，每个 worker 需要同步代码，不像 JMeter 那种「双击 agent 就启动」方便。
- 压测场景的「思考时间」需要用
time.sleep()手动控制，容易出偏差。
我建议，如果你的被测服务是小团队维护，压测场景经常变，用 Locust 最合适。改一段 Python 代码重启就行，不用重新打开一个笨重的 GUI。
4.2.3 wrk — 极简粗暴的 C 语言猛男
wrk 是我个人非常喜欢的工具。它就是一个 C 语言写的单机压测工具，没有 GUI、没有分布式、不搞花活。
优点：
- 性能极高——它在单机就能轻松压满 10G 带宽。
- 支持 Lua 脚本定制请求、参数化、延迟记录。
- 输出清晰：Latency、Req/Sec、Transfer/sec 三行搞定。
缺点：
- 只能压 HTTP/HTTPS，不支持 Cookie、Session 等复杂逻辑（需要 Lua 手写）。
- 不支持分布式，单机扛不住时就没辙了。
- 官方停止更新很久了，社区维护 fork 版本。
我用 wrk 的场景很固定：快速摸清一个 API 的极限 QPS，比如 Nginx 反代、Redis、MySQL 代理层。几分钟就能跑出一组数据，比 JMeter 启动还快。
4.2.4 ab — 老古董，但有些场景就是好用
ab (Apache Bench) 是 Apache 自带的压测工具，大多数人最早接触的压测工具就是它。
优点：
- 安装方便 — 装 Apache 就自带，或者
apt install apache2-utils。 - 参数简单：
-n 10000 -c 100谁都能看懂。 - 输出包含「请求耗时百分位」，够用了。
缺点：
- 单进程模型，并发高时会卡死。
- 不支持 POST 请求体参数化（只能写死的文件）。
- 不支持 Keep-Alive 精细控制。
说实话，生产环境我很少用 ab。但有一种情况例外——在部署脚本里做「快速健康检查」：
ab -n 100 -c 10 http://localhost:8080/health
能在几秒内确认服务上线后有没有崩。这个场景下 ab 反而比 wrk 方便，因为它不会因为连接关闭而报错中断。
4.3 选型决策流程
我画了一张图，帮你快速定位该用哪个工具。核心就一句话：从场景出发，别从工具出发。
4.4 选型落地建议
说了那么多，到底怎么选？我给你三个建议：
- 如果你只有一台压测机，目标就是测 HTTP 极限 — 用 wrk，别犹豫。它单机性能最高，输出也最清晰。
- 如果你需要模拟用户登录、购物车、下单的完整流程 — 用 JMeter 或 Locust。这俩都支持关联、参数化、断言。JMeter 自带组件多，Locust 写代码灵活。
- 如果你在写自动化测试脚本，压测只是 CI/CD 的一步 — 我建议选 Locust。它可以直接集成到 pytest，用
@locust.task装饰器搞定。
我的懒人推荐：
- 新手入门：先用 ab 跑通流程，再用 wrk 测极限，最后用 JMeter 搭复杂场景。
- 生产环境：JMeter 分布式 + Prometheus + Grafana 监控，基本是标配。
- 临时应急：手边没工具时，直接
curl -s -o /dev/null -w "%{http_code} %{time_total}"也能顶，但不推荐。
4.5 小结
选压测工具不是「哪个最强」，而是「哪个最适合你的当前场景」。我见过有人用 ab 跑了 1 万并发，结果压测机进程爆炸；也有人用 JMeter 测简单的健康检查，界面点了半天没启动——都是选错工具。
嗯，工具只是手段。你选对了，后面压测结果才有参考意义。选错了，那数据就是垃圾进垃圾出。