压测工具选型：JMeter、wrk、ab、Locust、Gatling 对比与选型策略
做性能压测这么多年，我经常被问到同一个问题：「到底该用哪个工具？」
说实话，没有银弹。每个工具都有自己的脾气。我见过有人用 JMeter 压一个简单的 API，结果自己先被配置搞崩溃了。也见过有人用 wrk 压复杂业务，发现连 Cookie 都带不上。
今天我就把这几款主流工具掰开揉碎讲清楚。你听完就知道，什么场景该选什么家伙。
核心观点：选工具不是选「最好的」，而是选「最合适的」。你的业务场景、团队技术栈、压测目标，这三者决定了最终答案。
一、先看一张全景图
下面这张 SVG 图，是我梳理的压测工具选型决策树。你跟着它走，基本不会跑偏。
二、逐个拆解：五款工具的真实面貌
1. ab (Apache Bench)
ab 是我最早接触的压测工具。那时候刚入行，领导让我「压一下看看」，我第一反应就是 ab。
它有多简单？一条命令搞定：
ab -n 10000 -c 100 http://example.com/api这行命令的意思是：总共发 10000 个请求，同时保持 100 个并发连接。
我的经验：ab 适合快速验证接口能不能扛住。比如你改了个配置，想看看 QPS 有没有下降，跑一下 ab 就出结果了。但别用它做复杂场景——它连 Cookie 都不好处理。
优点：
- 安装简单（Apache 自带）
- 命令简洁，上手快
- 结果输出清晰
缺点：
- 只支持 HTTP/HTTPS
- 不支持动态参数
- 无法模拟用户登录态
2. wrk
wrk 是我个人非常喜欢的一款工具。它用 C 语言写的，性能极好。我记得有一次压一个网关服务，用 JMeter 只能跑到 5000 QPS，换成 wrk 直接干到 20000+。
wrk -t12 -c400 -d30s http://example.com/api这条命令：用 12 个线程，保持 400 个连接，持续压 30 秒。
关键点：wrk 支持 Lua 脚本扩展。你可以用它实现复杂的请求构造、参数化、甚至断言。但说实话，Lua 脚本写起来有点费劲，调试也不方便。
适用场景：
- 需要高并发压测（10万+ QPS）
- 接口逻辑简单（GET/POST 为主）
- 对性能要求极致的场景
3. JMeter
JMeter 是压测界的「瑞士军刀」。功能全面到让你害怕——真的，我第一次打开 JMeter 的 GUI 界面时，看着满屏的配置项，愣了半天。
但它确实强大。举个例子，你要模拟一个用户登录 -> 浏览商品 -> 加入购物车 -> 下单的完整流程：
测试计划
├── 线程组（100个用户，持续10分钟）
│ ├── HTTP请求：登录（带参数化）
│ ├── JSON提取器：提取token
│ ├── HTTP请求：浏览商品（带token）
│ ├── HTTP请求：加入购物车
│ └── HTTP请求：下单
├── 监听器：聚合报告
└── 断言：响应状态码检查我曾经踩过的坑：JMeter 单机并发超过 1000 时，它自己先扛不住了。因为 JMeter 是 Java 写的，每个线程都是操作系统线程，资源消耗很大。后来我改用分布式模式，用 3 台机器才压到目标值。
优点：
- 功能最全面（支持 JDBC、JMS、FTP 等）
- GUI 界面，配置直观
- 插件生态丰富
- 支持分布式压测
缺点：
- 资源消耗大
- 脚本维护成本高
- 学习曲线陡峭
4. Locust
Locust 是个有意思的工具。它用 Python 写脚本，代码即配置。你想想看，对于 Python 开发者来说，这简直太友好了。
from locust import HttpUser, task, between
class WebsiteUser(HttpUser):
wait_time = between(1, 5)
@task
def index(self):
self.client.get("/")
@task(3)
def view_item(self):
self.client.get("/item?id=123")这段代码定义了一个用户行为：访问首页和查看商品详情，权重是 1:3。每个请求之间等待 1-5 秒。
我的建议：如果你的团队以 Python 为主，Locust 是首选。它天然支持分布式，而且 Web UI 做得不错。但说实话，它的性能不如 wrk，单机并发到 5000 左右就开始吃力了。
5. Gatling
Gatling 是用 Scala 写的，性能介于 JMeter 和 wrk 之间。它的特点是代码化压测脚本，而且报表生成非常漂亮。
class BasicSimulation extends Simulation {
val httpProtocol = http.baseUrl("http://example.com")
val scn = scenario("BasicSimulation")
.exec(http("request_1").get("/api"))
.pause(5)
setUp(scn.inject(atOnceUsers(100))).protocols(httpProtocol)
}Gatling 的报表是我见过最专业的。它会把响应时间分布、吞吐量、错误率全部可视化。我在做性能调优汇报时，经常直接用 Gatling 的报表截图。
三、选型策略：一张表说清楚
| 场景 | 推荐工具 | 理由 |
|---|---|---|
| 快速验证接口 | ab / wrk | 一条命令搞定，不需要写脚本 |
| 复杂业务流程 | JMeter / Gatling | 支持参数化、断言、事务控制 |
| 高并发压测（10万+） | wrk | 性能最好，资源消耗最低 |
| 团队以 Python 为主 | Locust | 代码即脚本，维护成本低 |
| 需要专业报表 | Gatling | 报表最漂亮，适合汇报 |
| 分布式压测 | JMeter / Locust | 原生支持分布式架构 |
四、我的选型心法
做了这么多年压测，我总结了一套选型逻辑：
- 先看场景复杂度。如果只是压一个 GET 接口，ab 或 wrk 就够了。别杀鸡用牛刀。
- 再看团队技术栈。Java 团队用 JMeter，Python 团队用 Locust，Scala 团队用 Gatling。别为了工具学一门新语言。
- 最后看性能要求。目标 QPS 超过 5 万，直接上 wrk。JMeter 和 Locust 在这个量级下，自己先成了瓶颈。
记住一句话：压测工具是手段，不是目的。你的目标是发现系统瓶颈，而不是把工具玩出花来。
嗯，关于工具选型就聊这么多。每种工具都有它的脾气，你用得多了自然就懂了。关键是多动手，别光看文档。我见过太多人把时间花在「选工具」上，结果项目都结束了还没开始压。
想要更多资料，联系可可