4. 测试工具选型：JMeter、Locust、wrk、自研压测平台的优劣对比
做压力测试，选工具是第一道坎。
我见过不少团队，一上来就纠结「哪个工具最好」。其实没有最好的工具，只有最合适的。你想想看，测一个HTTP接口和测一个TCP网关，能一样吗？
今天我就把市面上主流的四类压测工具掰开揉碎讲清楚。JMeter、Locust、wrk，还有自研压测平台。每个我都踩过坑，有些坑至今记忆犹新。
4.1 JMeter：老牌劲旅，功能全面
JMeter 是我最早接触的压测工具。说实话，它的 GUI 界面确实有点「复古」，但功能是真的扎实。
优点：
- 协议支持广：HTTP、HTTPS、TCP、JDBC、JMS……你能想到的协议它基本都支持。我在项目中用它测过行情推送的WebSocket连接，虽然配置起来麻烦点，但能跑通。
- 断言和监听器丰富：响应断言、JSON断言、图形结果、聚合报告……调试起来很方便。
- 分布式压测：一台机器不够？可以搞主从模式。不过我要提醒你，这个分布式方案在网络抖动时容易出问题，我踩过这个坑。
缺点：
- 资源消耗大：Java 写的，启动就占几百兆内存。压测线程一多，CPU 先扛不住了。我曾经用 JMeter 压 2000 并发，结果压测机自己先挂了。
- 脚本维护成本高：GUI 录制的脚本可读性差，参数化、关联处理起来很繁琐。团队里如果有人改了接口，你得重新录一遍。
- 不适合高并发场景：单机撑死 3000-5000 并发，再往上就得靠分布式。但分布式又引入了新的问题。
我的建议：JMeter 适合功能验证、接口调试、低并发场景。如果你团队里测试人员偏手工，JMeter 的 GUI 反而是优势。
4.2 Locust：Python 党的最爱
Locust 是后来崛起的工具。它的核心卖点就一个：用 Python 写压测脚本。
优点：
- 脚本灵活：Python 代码即脚本，想怎么玩就怎么玩。我习惯把压测逻辑封装成类，复用性很高。
- 协程机制：基于 gevent 的协程，单机并发能力比 JMeter 强不少。我测过，单机能撑到 1 万左右的并发。
- Web UI 实时监控：启动后有个漂亮的 Web 页面，可以实时看 TPS、响应时间、失败率。这个体验比 JMeter 好太多。
缺点：
- 协议支持有限：原生只支持 HTTP/HTTPS。要测 TCP、WebSocket 得自己写客户端。嗯，这里要注意，自己写的客户端性能可能不如原生实现。
- 分布式配置麻烦：虽然支持 master-worker 模式，但 worker 节点的注册、数据同步经常出问题。我曾经在 20 台机器上部署 Locust 集群，光调试网络就花了一天。
- 报告功能弱：自带的报告太简单，没有 JMeter 那种聚合报告、图形报告。你得自己写脚本导出数据，再用 Excel 或 Grafana 展示。
避坑指南：我曾经用 Locust 压测一个 WebSocket 行情网关，发现协程模式下连接数上不去。后来排查发现是 gevent 的 monkey patch 和 WebSocket 库有冲突。解决方案是改用 threading 模式，虽然性能下降了一些，但至少能跑通。
4.3 wrk：轻量级利器，专攻 HTTP
wrk 是我个人最常用的压测工具。它轻量、高效、专注。
优点：
- 性能极致：基于 C 语言 + libuv 事件驱动，单机轻松压到 10 万并发。我测试过，一台 8 核机器用 wrk 压 Nginx，CPU 利用率能到 90% 以上。
- Lua 脚本扩展：虽然 wrk 本身只支持 HTTP，但通过 Lua 脚本可以实现请求参数化、响应校验、自定义报告。我习惯用 Lua 写一个简单的请求生成器，模拟不同用户的登录态。
- 启动即用：没有 GUI，没有配置文件，一条命令搞定。适合快速验证。
缺点：
- 协议单一：只支持 HTTP/HTTPS。要测 TCP、WebSocket 就别想了。
- 报告简陋：只有命令行输出，没有图形界面。延迟分布、百分位数据需要自己解析。
- 调试困难：Lua 脚本出错时，错误信息不友好。我经常得在脚本里加 print 来调试。
我的建议：wrk 适合做基准测试、容量评估。比如上线前快速压一下接口，看看 TPS 和延迟是否达标。但别用它做复杂的业务场景压测。
4.4 自研压测平台：大厂的终极选择
说实话，当你的系统达到一定规模，市面上的工具都不够用。这时候就得自研了。
优点：
- 完全可控：想怎么压就怎么压。我参与过自研平台的架构设计，支持自定义协议、动态参数、流量录制回放、全链路压测。
- 分布式调度：可以调度上千台压测机，模拟百万级并发。而且支持动态扩缩容，压测过程中随时加机器。
- 数据闭环：压测数据直接写入时序数据库，实时展示 TPS、延迟、错误率、CPU/内存/网络等指标。还能和 APM 系统联动，自动定位瓶颈。
- 场景编排：支持复杂的业务场景编排，比如先登录、再下单、再撤单，每一步都有依赖关系。
缺点：
- 开发成本高：一个可用的自研平台，至少需要 3-5 人开发半年。包括压测引擎、调度系统、数据采集、报告展示、权限管理……
- 维护成本高：系统升级、Bug 修复、兼容性测试，都是持续投入。我见过不少团队自研到一半就放弃了。
- 学习曲线陡：团队成员需要熟悉平台的使用方式、脚本编写、结果分析。不像 JMeter 那样开箱即用。
重要提醒：自研压测平台不是银弹。如果你的系统并发量在 1 万以下，用 wrk 或 Locust 完全够用。别为了「炫技」而自研，那是给自己挖坑。
4.5 核心对比：一张表说清楚
| 维度 | JMeter | Locust | wrk | 自研平台 |
|---|---|---|---|---|
| 协议支持 | 丰富（HTTP/TCP/JDBC等） | 有限（HTTP为主） | 单一（仅HTTP） | 自定义（想支持什么就支持什么） |
| 单机并发能力 | 3000-5000 | 5000-10000 | 10万+ | 取决于引擎实现，通常10万+ |
| 脚本灵活性 | 中等（GUI配置） | 高（Python代码） | 中等（Lua脚本） | 极高（自定义DSL或代码） |
| 报告能力 | 丰富（图形/聚合/表格） | 一般（Web实时+简单报告） | 简陋（命令行输出） | 强大（自定义仪表盘+APM联动） |
| 分布式支持 | 有（但配置复杂） | 有（但网络问题多） | 无（单机模式） | 原生支持（调度上千台机器） |
| 学习成本 | 低（GUI操作） | 中（需Python基础） | 低（命令行） | 高（需熟悉平台） |
| 维护成本 | 低 | 中 | 低 | 高（持续开发+运维） |
| 适用场景 | 功能验证、低并发、多协议 | 中并发、HTTP场景、Python团队 | 基准测试、容量评估、快速验证 | 高并发、复杂场景、全链路压测 |
4.6 选型建议：别纠结，看场景
说了这么多，到底怎么选？我给出一个简单的决策路径：
- 先看并发量：如果目标并发在 5000 以下，JMeter 或 Locust 都行。5000-10000，Locust 更合适。10000 以上，wrk 或自研平台。
- 再看协议：如果只测 HTTP，wrk 是首选。如果涉及 TCP、WebSocket、JDBC 等，JMeter 或自研平台。
- 再看团队：如果团队以测试人员为主，JMeter 的 GUI 更友好。如果团队有开发背景，Locust 或自研平台更灵活。
- 最后看预算：自研平台成本最高，但长期来看收益也最大。如果公司不差钱，直接上自研。
我的经验：我习惯在项目初期用 wrk 做快速基准测试，了解系统的极限在哪里。然后在功能测试阶段用 JMeter 做场景验证。最后在性能调优阶段用自研平台做全链路压测。三个工具各司其职，互不冲突。
4.7 知识体系图：工具选型决策树
下面这张图是我自己总结的选型决策树，你可以对照着看：
最后说一句：工具只是手段，不是目的。真正重要的是你如何设计压测场景、如何分析结果、如何定位瓶颈。工具选对了，能省一半的力。选错了，那就是给自己挖坑。
嗯，这一章就到这里。下一章我们聊聊压测场景的设计，那才是真正考验功力的地方。
公众号:蓝海资料掘金营，微信deep3321