压测工具选型：JMeter、Locust、wrk、ab、Go-stress-testing 对比与选型策略
做性能压测这么多年，我经常被问到同一个问题：「到底该用哪个工具？」
说实话，没有银弹。每个工具都有自己的脾气。我见过有人用 ab 压测长连接接口，结果数据完全不准。也见过团队用 JMeter 压测一个简单的 HTTP GET，配置搞了两天。
今天我就把常用的几款工具掰开揉碎讲清楚。你听完就知道，什么场景该选什么工具。
核心观点：选工具不是选「最好的」，而是选「最合适的」。压测工具的核心能力就三样——施压能力、数据采集能力、脚本维护成本。
一、工具全景对比
先看一张总览表。我按自己的使用经验，把主流工具分了类。
| 工具 | 语言 | 协议支持 | 并发模型 | 学习成本 | 适合场景 |
|---|---|---|---|---|---|
| JMeter | Java | HTTP/HTTPS/WebSocket/gRPC/数据库等 | 线程池 | 中 | 复杂业务场景、分布式压测 |
| Locust | Python | HTTP/WebSocket/自定义 | 协程（gevent） | 低 | 快速脚本、Python 技术栈团队 |
| wrk | C/Lua | HTTP/HTTPS | 多线程 + epoll | 高 | 高并发基准测试 |
| ab | C | HTTP/HTTPS | 多进程 | 极低 | 快速验证、简单 GET 请求 |
| Go-stress-testing | Go | HTTP/HTTPS | goroutine | 低 | 轻量级压测、快速上手 |
我的建议：如果你团队里 Python 多，优先考虑 Locust。如果 Java 多，JMeter 更稳妥。如果只是自己测个接口性能，wrk 或 Go-stress-testing 就够了。
二、逐个工具深度分析
1. JMeter —— 老牌王者，功能最全
JMeter 是我用得最多的工具。说实话，它有点重，但确实能打。
它的优势在于协议支持极其丰富。HTTP、WebSocket、gRPC、JDBC……几乎你能想到的协议它都支持。而且有 GUI 界面，配置起来直观。
但我得提醒你一个坑：JMeter 的线程模型是 Java 线程。单机并发到 2000 以上时，GC 压力会很大。我曾经压一个 WebSocket 服务，开到 3000 线程，JMeter 自己先挂了。
避坑指南：JMeter 做高并发压测时，一定要用命令行模式（非 GUI）。GUI 模式本身就会消耗大量资源。我曾经在 GUI 模式下压测，结果数据偏差了 30%。
2. Locust —— Python 党的最爱
Locust 的设计理念我很喜欢——用代码定义压测行为。你写一个 Python 类，继承 HttpUser，然后定义 task。就这么简单。
它的并发模型是协程（gevent），单机并发能力比 JMeter 强不少。我试过用 Locust 单机压到 5000 QPS，CPU 占用才 60%。
不过 Locust 也有短板：协议支持有限。原生只支持 HTTP/HTTPS，WebSocket 需要自己写扩展。如果你要压测数据库或 gRPC，Locust 就不太合适了。
3. wrk —— 极简主义者的利器
wrk 是我个人最喜欢的基准测试工具。它用 C 语言写的，底层用 epoll 实现事件驱动，性能极高。
用法也简单：
wrk -t12 -c400 -d30s http://target.com/api这条命令的意思是：12 个线程，400 个连接，持续 30 秒。输出结果里直接告诉你 QPS、延迟分布。
但 wrk 有个硬伤：脚本能力弱。虽然支持 Lua 脚本，但写起来很痛苦。我试过用 wrk 模拟登录流程，Lua 脚本写了 100 多行，调试了一下午。
适用场景：wrk 最适合做「纯压力测试」。比如你想知道一个接口的极限 QPS 是多少，用 wrk 最直接。但如果你需要复杂的业务逻辑，别用它。
4. ab —— 最轻量的选择
ab（Apache Bench）是 Apache 自带的压测工具。安装 Apache 后就能用，几乎零学习成本。
用法：
ab -n 10000 -c 100 http://target.com/但 ab 的问题也很明显：功能太简陋。它只支持 HTTP/HTTPS，而且只能做 GET 请求。POST 请求虽然支持，但需要自己写文件。
我一般只在「快速验证」时用 ab。比如刚部署完服务，想确认一下能不能正常响应，跑一下 ab 就够了。
5. Go-stress-testing —— 国产新秀
这个工具是 Go 语言写的，最近在 GitHub 上挺火。它的特点是安装简单、上手快。
用法：
go-stress-testing -c 100 -n 10000 -u http://target.com/api它底层用 goroutine 实现并发，性能不错。而且输出结果很友好，直接告诉你 QPS、平均延迟、错误率。
不过它目前只支持 HTTP/HTTPS，协议支持上不如 JMeter 和 Locust。适合做轻量级的压测任务。
三、选型策略：我总结的「三看原则」
选工具其实没那么复杂。我总结了三步：
- 看协议需求：如果只压 HTTP，wrk/ab/Go-stress-testing 都行。如果需要 WebSocket/gRPC/数据库，直接选 JMeter。
- 看团队技术栈：Python 团队用 Locust，Java 团队用 JMeter，Go 团队可以考虑 Go-stress-testing。
- 看压测规模：单机 2000 并发以内，JMeter 够用。超过 2000，建议用 Locust 或 wrk。
我的经验：实际项目中，我经常「组合使用」。比如先用 wrk 做基准测试，摸清接口的极限 QPS。然后用 JMeter 做复杂场景压测，模拟真实用户行为。这样既快又准。
四、知识体系总览
下面这张图，是我对压测工具选型的整体理解。你可以把它当作决策地图。
五、我的最终建议
说了这么多，其实就一句话：别纠结工具，先搞清楚你要测什么。
如果你只是想知道接口的极限 QPS，wrk 或 ab 就够了。如果你要模拟真实用户行为，JMeter 或 Locust 更合适。如果你团队里都是 Python 开发者，别硬上 JMeter，Locust 会让你们更舒服。
嗯，工具选型这件事，说白了就是「匹配」。匹配你的需求、匹配你的团队、匹配你的场景。选对了，事半功倍。选错了，光调试工具就能耗掉你半天时间。
最后提醒一句：不管选哪个工具，压测前一定要先做「小规模验证」。我见过太多人一上来就开 1000 并发，结果工具配置错了，数据全废。先跑 10 个请求看看结果对不对，再上量。
想要更多资料，联系可可