3、压测工具选型：JMeter、wrk、Locust、Gatling的对比与适用场景
做压测这么多年，我经常被问到同一个问题：「到底该用哪个工具？」
说实话，没有银弹。每个工具都有自己的脾气。我见过有人用JMeter压一个简单的API，结果自己先被JMeter搞崩溃了。也见过有人用wrk测复杂业务逻辑，测出来的数据完全没法看。
这一章，我就把四个主流工具掰开揉碎讲清楚。你听完就知道，什么场景该选谁。
3.1 四款工具的核心定位
先给个总览。我习惯把压测工具分成两类：「轻量级狙击枪」和「重型火炮」。
核心结论：
- wrk —— 狙击枪。单机并发能力极强，适合测接口极限QPS。
- JMeter —— 瑞士军刀。功能最全，但学习成本高，资源消耗大。
- Locust —— Python党的最爱。脚本灵活，但性能一般。
- Gatling —— 性能与报表兼得。Scala写脚本，门槛略高。
你想想看，如果你只是想知道一个接口能抗多少并发，拿wrk就够了。但如果你要做全链路压测，带登录态、带参数关联、带断言，那wrk就完全不够用了。
3.2 详细对比：从四个维度拆解
3.2.1 性能与资源消耗
这是最硬核的指标。我直接给数据，都是我在项目中实测过的。
| 工具 | 单机最大并发 | CPU/内存消耗 | 适合场景 |
|---|---|---|---|
| wrk | 5万+ | 极低 | 单接口极限压测 |
| JMeter | 3000~5000 | 较高 | 复杂业务场景 |
| Locust | 2000~4000 | 中等 | Python生态集成 |
| Gatling | 1万+ | 较低 | 高性能+报表需求 |
嗯，这里要注意。JMeter的瓶颈其实不在工具本身，而在Java的线程模型。每个虚拟用户就是一个线程，线程多了GC就炸。我曾经用JMeter压一个网关，并发到4000的时候，JMeter自己先OOM了。后来换了Gatling，同样的脚本跑到1.2万并发，机器还很稳。
3.2.2 脚本编写与灵活性
我个人最看重这一点。因为压测脚本的维护成本，往往比压测本身还高。
- wrk：用Lua写脚本。简单接口还行，复杂逻辑写起来想哭。我一般只用它做快速验证。
- JMeter：图形化拖拽。上手容易，但一旦涉及if-else、循环、参数化，就得加各种插件，配置项多到眼花。
- Locust：纯Python。这是我最喜欢的。你可以用requests库、pandas处理数据、甚至调sklearn做实时分析。灵活度拉满。
- Gatling：Scala DSL。语法优雅，但团队里得有Scala高手。我见过不少团队因为没人会Scala，最后把Gatling脚本写成了Java风格，反而更丑。
我的建议：
如果你的团队Python基础好，无脑选Locust。如果追求极致性能且愿意学Scala，Gatling是首选。JMeter适合「一次压测，用完即弃」的场景。
3.2.3 报表与可视化
说实话，很多工具自带的报表都挺丑的。但Gatling是个例外。
- wrk：只有命令行输出。你得自己写脚本解析结果。
- JMeter：有聚合报告、图形结果。但说实话，那个界面风格还停留在2005年。
- Locust：Web实时图表。能看到RPS、响应时间、失败率。够用，但不精致。
- Gatling：生成HTML报表。有响应时间分布图、百分位线、吞吐量趋势。我每次给老板汇报都用Gatling的报表，直接截图放PPT里，不用再加工。
3.2.4 分布式压测支持
单机压不动的时候，就得分布式上场了。
- wrk：不支持分布式。你得自己写脚本在多台机器上跑，然后汇总结果。
- JMeter：支持Master-Slave模式。但配置起来挺麻烦的，网络不通、版本不一致、参数同步，坑不少。
- Locust：原生支持分布式。启动时加个
--master和--worker参数就行。我曾在100台机器上跑过Locust集群，压到了50万并发。 - Gatling：企业版支持分布式。开源版需要自己用Maven/SBT集成，有点折腾。
3.3 知识体系图：压测工具选型决策流程
下面这张图，是我根据多年经验总结的选型决策树。你照着走，基本不会选错。
3.4 避坑指南
我曾经踩过的坑：
- 用wrk测带登录态的接口 —— wrk不支持Cookie自动管理，你得手动在Lua脚本里处理。我那次折腾了一下午，最后换Locust十分钟搞定。
- JMeter分布式压测时网络不通 —— 记得检查Agent和Master之间的防火墙。我那次压测前忘了开端口，结果压了半小时全是错误数据。
- Gatling的Scala版本冲突 —— 不同版本的Gatling对Scala版本有要求。我建议直接用Gatling官方提供的Maven Archetype创建项目，省心很多。
3.5 我的最终建议
说了这么多，我直接给结论：
- 快速验证接口性能 → wrk。写个Lua脚本，10分钟出结果。
- 复杂业务压测，团队有Python基础 → Locust。灵活、可扩展、分布式方便。
- 需要高性能+漂亮报表 → Gatling。虽然学习曲线陡，但值得投入。
- 公司要求统一工具，或者团队啥都不会 → JMeter。生态最全，遇到问题百度一下都有答案。
记住，工具只是手段。真正重要的是你如何设计压测场景、如何分析结果。下一章，我会讲压测场景的设计方法论，那才是真正的硬功夫。
一句话总结：
wrk打头阵，Locust/Gatling打主力，JMeter兜底。这是我压了上百个项目总结出来的黄金组合。
想要更多资料，联系可可