压测工具选型：JMeter、Locust、wrk、ab、Go-stress-testing 的对比与选型策略
做压测这么多年，我经常被问到同一个问题：「到底该用哪个工具？」
说实话，没有银弹。每个工具都有自己的脾气。我见过有人用 ab 测 WebSocket，结果测了个寂寞；也见过团队用 JMeter 压一个简单的 API，光配置就花了两天。
今天我把主流工具拉出来遛一遛。你想想看，选工具就像选螺丝刀——拧十字螺丝你用一字刀，那不是跟自己过不去吗？
核心观点：选工具不是选「最好的」，而是选「最合适的」。你的业务场景、团队技术栈、压测目标，这三者决定了答案。
一、先看一张全景图
下面这张图是我自己整理的，把五个工具的核心定位画了出来。你看一眼就能明白个大概。
嗯，这张图其实透露了一个信息：没有工具能同时站在右上角。功能越强，往往性能开销越大；性能越极致，功能就越简陋。这是 trade-off，你得接受。
二、逐个拆解：每个工具的长短处
1. JMeter —— 压测界的「瑞士军刀」
我个人习惯把 JMeter 当作主力工具。为什么？因为它太全面了。HTTP、JDBC、JMS、FTP、甚至 gRPC 都能测。你想想看，一个工具能覆盖这么多协议，这在团队协作时特别省心。
但 JMeter 也有它的毛病。我记得有一次压一个高并发接口，开到 2000 线程时，JMeter 自己先卡死了。后来排查发现，是 GUI 模式下的资源消耗太大。说白了，JMeter 的 Java 虚拟机本身就要吃掉不少内存。
我的建议：JMeter 适合做复杂业务场景的压测，尤其是需要参数化、断言、监听器组合的场景。但别用它做「纯性能测试」——就是那种只关心 QPS 的场景，用 wrk 更合适。
2. Locust —— Python 玩家的最爱
Locust 最大的亮点是：用 Python 写压测脚本。如果你团队里都是 Python 工程师，那 Locust 简直是天选之子。它的协程模型让单机并发能力远超 JMeter。
不过，Locust 的坑也不少。我曾经遇到过一个项目，用 Locust 压测时，Python 的 GIL 锁导致 CPU 跑不满。后来改成多进程模式才解决。嗯，这里要注意：Locust 的 worker 进程数要跟 CPU 核数匹配，不是越多越好。
避坑指南：我曾经用 Locust 压测一个长连接服务，结果发现 Locust 默认的 HTTP 客户端会复用连接，导致压测结果偏乐观。后来我强制禁用了连接复用，才拿到真实数据。
3. wrk —— 性能怪兽
wrk 是用 C 语言写的，底层基于 Redis 的 ae 事件循环。说白了，它就是为了「压出极限」而生的。我见过有人用 wrk 单机压出 10 万 QPS，而同样的机器用 JMeter 只能压到 2 万。
但 wrk 的短板也很明显：只能测 HTTP 协议，而且脚本能力极弱。你想做复杂的参数化？对不起，不支持。你想做断言？也没有。
我个人习惯把 wrk 当作「快速验证工具」。比如上线前，先跑一把 wrk 看看接口的毛刺情况。如果 wrk 都扛不住，那就不用上 JMeter 了。
4. ab —— 古董级工具
ab 是 Apache 自带的压测工具，简单到令人发指。一条命令就能跑起来：
ab -n 10000 -c 100 http://example.com/但它的缺点也很致命：不支持 HTTP/2，不支持 Keep-Alive 的精细控制。我记得有一次用 ab 压测一个 HTTPS 站点，结果 SSL 握手开销占了 60% 的 CPU，压测数据完全失真。
所以我的态度很明确：ab 只适合做「能不能通」的冒烟测试，别拿它做正式压测。
5. Go-stress-testing —— 后起之秀
这个工具是 Go 语言写的，最近几年在中文社区挺火。它的优势是：部署简单、单文件、跨平台。而且 Go 的 goroutine 模型让并发能力很强。
我试用过一次，感觉它的设计思路跟 wrk 有点像，但多了一些实用功能，比如支持自定义 Header、支持 JSON 格式的请求体。不过，它的生态还比较弱，社区文档也不够完善。
一句话总结：如果你想要一个「比 wrk 功能多一点，比 JMeter 轻量很多」的工具，Go-stress-testing 值得一试。
三、选型策略：到底怎么选？
我整理了一个决策表，你直接对着看就行：
| 场景 | 推荐工具 | 理由 |
|---|---|---|
| 复杂业务流程压测（多接口、参数化、断言） | JMeter | 功能最全，社区最成熟 |
| Python 技术栈团队 | Locust | 脚本友好，协程模型高效 |
| 单接口极限压测（追求 QPS） | wrk | C 语言实现，性能极致 |
| 快速冒烟测试 | ab | 一条命令搞定，零配置 |
| 轻量级压测、快速验证 | Go-stress-testing | 单文件部署，Go 并发模型 |
| 分布式压测 | JMeter + Locust | 两者都支持分布式部署 |
你可能会问：「那我能不能混着用？」
当然可以。我自己的习惯是：先用 wrk 摸上限，再用 JMeter 做场景。这样既快又准。你想想看，如果 wrk 都压不上去，那 JMeter 就更没戏了，对吧？
四、避坑指南：我踩过的那些坑
- 别用 GUI 模式跑高并发：JMeter 的 GUI 模式会吃掉大量资源。我习惯在命令行跑：
jmeter -n -t test.jmx -l result.jtl - 注意 Locust 的 Python 版本：Python 3.8 以下版本有协程 bug，会导致压测数据不准。我建议用 Python 3.10+
- wrk 的 Lua 脚本别写太复杂：wrk 的 Lua 脚本是同步执行的，写复杂了反而拖慢性能。保持脚本在 20 行以内
- ab 的 -c 参数别开太大：ab 的并发模型是 fork 进程，开太多进程会导致系统上下文切换开销暴增。我一般不超过 100
- Go-stress-testing 注意内存泄漏：这个工具还在快速迭代中，我遇到过长时间压测后内存泄漏的问题。建议每次压测不超过 30 分钟
五、最后说两句
选工具这件事，说白了就是「看人下菜碟」。你团队擅长什么、你要测什么场景、你有多长时间，这三个问题想清楚了，答案自然就有了。
我个人建议：团队里至少备两个工具——一个重型（JMeter 或 Locust），一个轻型（wrk 或 Go-stress-testing）。这样不管遇到什么场景，你都有牌可打。
嗯，今天就聊到这儿。工具只是手段，真正重要的是你对系统的理解。下一章我们聊聊压测场景的设计，到时候见。