压测工具选型：wrk、JMeter、Locust、自研工具对比
做交易系统压测，选工具是个头疼事。我见过不少团队，一上来就怼着JMeter猛干，结果发现连个TCP连接都模拟不好。也见过有人用wrk跑HTTP，跑得飞起，但一问能不能发自定义协议包，直接傻眼。
说白了，没有万能工具。只有适合你场景的工具。今天我就把这几个主流工具掰开揉碎，结合我踩过的坑，给你讲明白。
一、先看一张图，理清思路
下面这张图，是我自己总结的选型决策流程。你照着走一遍，基本不会选错。
二、逐个工具拆解
1. wrk —— 轻量级HTTP压测利器
wrk是我个人最常用的工具之一。它基于C语言和libuv事件循环，单机就能压出几十万QPS。你想想看，一个几MB的二进制文件，跑起来比JMeter轻快多了。
但wrk有个硬伤：只支持HTTP协议。交易系统里很多场景是自定义TCP协议，或者FIX协议，wrk就无能为力了。
适用场景：
- RESTful API接口压测
- WebSocket行情推送压测
- 快速验证单机吞吐上限
我的经验： 有一次压测行情网关，wrk跑出50万QPS，但实际生产只有10万。后来发现wrk的keep-alive连接复用太理想化，真实网络环境根本达不到。所以wrk的结果要打折扣看。
2. JMeter —— 功能全面但笨重
JMeter是Java生态的老牌工具。插件丰富，能压HTTP、JDBC、JMS，甚至能写Groovy脚本模拟复杂业务逻辑。我见过有人用它压测撮合引擎的数据库连接池，确实方便。
但JMeter的并发模型是基于线程的。你想想看，Java线程开销大，一台机器开1000个线程，CPU就飙到80%了。而wrk用事件驱动，同样资源能跑10倍并发。
避坑指南： 我曾经用JMeter压测一个低延迟交易系统，结果JMeter本身成了瓶颈。客户端CPU打满，服务端才用了20%。后来换成自研工具，才压出真实上限。所以JMeter适合压测业务逻辑复杂的场景，不适合追求极致吞吐。
3. Locust —— Python玩家的选择
Locust用Python写测试脚本，上手快。它的并发模型基于协程（gevent），比JMeter的线程模型轻量。我团队里有个量化研究员，半天就写出了一个FIX协议的压测脚本。
但Locust的弱点也很明显：Python的GIL锁限制了CPU利用率。单机压测，Locust的吞吐上限大概在5-10万QPS，再高就吃力了。
适用场景：
- 快速原型验证
- 非核心系统的压测
- 团队以Python为主的场景
4. 自研工具 —— 终极方案
说实话，交易系统压测做到最后，大部分团队都会走向自研。为什么？因为交易系统的协议太特殊了。FIX协议、CTP协议、自定义二进制协议，这些通用工具都不支持。
我参与过的一个项目，自研压测工具用C++写的，基于DPDK收发包，单机压出了200万QPS。当然，自研成本也高，一个成熟的压测框架，开发周期至少2-3个月。
我的建议： 不要一上来就自研。先用wrk或JMeter跑通流程，找到瓶颈点。等确定需要定制协议或极致性能时，再投入自研。我见过太多团队，花3个月自研工具，结果发现wrk加个Lua脚本就能搞定。
三、核心对比表格
| 维度 | wrk | JMeter | Locust | 自研工具 |
|---|---|---|---|---|
| 协议支持 | 仅HTTP | HTTP/数据库/消息队列 | HTTP/自定义 | 完全自定义 |
| 并发模型 | 事件驱动 | 多线程 | 协程 | 按需设计 |
| 单机吞吐 | 50万+ QPS | 5-10万 QPS | 5-10万 QPS | 100万+ QPS |
| 学习成本 | 低 | 中 | 低 | 高 |
| 定制灵活性 | 低（Lua脚本有限） | 中（插件/Groovy） | 中（Python脚本） | 高 |
| 适合场景 | HTTP接口压测 | 复杂业务压测 | 快速原型 | 低延迟/自定义协议 |
四、选型决策指南
说了这么多，到底怎么选？我给你一个三步走策略：
- 先看协议： 如果只是HTTP，wrk优先。如果有自定义协议，直接考虑自研或Locust。
- 再看并发： 需要百万级并发？自研或wrk。几万并发？JMeter或Locust都行。
- 最后看团队： 团队Java多，用JMeter。Python多，用Locust。C++多，自研。
我的经验总结： 交易系统压测，80%的场景用wrk+自研脚本就能覆盖。剩下20%的复杂场景，才需要JMeter或Locust。别把工具选型搞得太复杂，先跑起来再说。
五、一个真实案例
去年我帮一个期货公司做压测。他们的交易网关用的是FIX协议，内部还夹了一层加密。一开始他们用JMeter，写了个Java插件处理加密，结果压到3万QPS就上不去了。
我过去一看，JMeter的线程模型把CPU都吃在上下文切换上了。后来我们用C++自研了一个压测工具，基于epoll+线程池，直接压到30万QPS。嗯，这里要注意，自研工具虽然强，但开发周期花了3周。如果项目时间紧，还是得权衡。
所以我的建议是：先用wrk验证基础性能，再用自研工具压极限。 这样既快又准。
公众号:蓝海资料掘金营，微信deep3321