压测工具全景图：开源工具 vs 商业工具
做性能压测这么多年，我见过不少团队在工具选型上栽跟头。有人迷信商业工具，觉得花钱买的才靠谱；也有人死磕开源，结果遇到瓶颈时才发现兜不住。其实说白了，工具没有的好坏，关键看你的场景和团队能力。
这一章，我带你把市面上主流的压测工具捋一遍。我会从开源和商业两个维度切入，再重点对比几个常见工具——JMeter、Locust、Gatling、wrk、Vegeta。嗯，这些都是我实际项目中摸爬滚打用过的，坑和亮点都清楚。
开源工具 vs 商业工具：怎么选？
先聊个大方向。开源工具和商业工具，本质上不是谁替代谁的关系，而是互补。我个人的习惯是：日常研发、小规模压测、快速验证，用开源；关键业务、大规模并发、需要合规审计，上商业。
为什么会这样？你想想看，开源工具的优势很明显——免费、社区活跃、插件丰富。但短板也致命：缺乏统一的技术支持，遇到底层 bug 只能自己啃源码。我曾经在一个高并发项目里，用开源工具压到 10 万 QPS 时，工具本身先挂了，排查了两天才发现是连接池泄漏。嗯，那种感觉，懂的都懂。
商业工具呢？贵，但省心。像 LoadRunner、NeoLoad 这些，自带监控、报表、分布式调度，甚至能直接对接 APM 系统。适合大企业、金融、电信这些对稳定性和合规性要求极高的场景。不过，商业工具的脚本录制功能往往过于笨重，我见过不少团队买了 License 却只用了个零头，最后又偷偷切回开源。
我的建议：团队技术能力强、预算有限，优先选开源；业务价值高、容错率低，别省那点钱，上商业工具。最怕的是两头不靠——用开源又嫌没支持，用商业又嫌贵，最后工具成了瓶颈。
常见工具对比：JMeter / Locust / Gatling / wrk / Vegeta
下面这五款工具，基本覆盖了 90% 的压测场景。我按自己的使用经验，从几个关键维度做了个对比表，你先扫一眼。
| 工具 | 协议支持 | 脚本语言 | 并发模型 | 分布式 | 学习曲线 | 适用场景 |
|---|---|---|---|---|---|---|
| JMeter | HTTP/HTTPS、JDBC、JMS、FTP 等 | GUI 配置 + BeanShell | 线程池 | 原生支持 | 低 | 全协议、复杂业务流程 |
| Locust | HTTP/HTTPS（可扩展） | Python | 协程（gevent） | 原生支持 | 中 | 高并发、自定义逻辑 |
| Gatling | HTTP/HTTPS、WebSocket、JMS | Scala DSL | Akka Actor | 原生支持 | 中高 | 高并发、CI/CD 集成 |
| wrk | HTTP/HTTPS | Lua | 多线程 + epoll | 需手动 | 低 | 单机高并发、快速压测 |
| Vegeta | HTTP/HTTPS | 命令行 + JSON | 多线程 | 需手动 | 极低 | 持续压测、管道化 |
这张表只是入门。下面我逐个展开，说说每个工具的核心特点，以及我在项目中踩过的坑。
JMeter：全协议、重生态，但小心内存
JMeter 是我最早接触的压测工具，也是目前国内使用率最高的。它的优势在于协议支持极其丰富——HTTP、JDBC、JMS、FTP、甚至自定义协议都能搞。而且社区插件多，几乎你能想到的监控、报表、断言都有现成的。
但 JMeter 有个老毛病：线程模型太重。每个虚拟用户就是一个线程，压到几千并发时，JVM 内存和 GC 就成了瓶颈。我曾经在压测一个电商秒杀接口时，JMeter 客户端自己先 OOM 了，排查了半天才发现是监听器配置太多，把结果全写到了内存里。
避坑指南：用 JMeter 做高并发压测时，记得关掉不必要的监听器（比如 View Results Tree），改用命令行模式执行。命令行下用 -n -t 参数，结果输出到 CSV，能省下大量内存。
Locust：Python 党的最爱，协程是双刃剑
Locust 最大的亮点是用 Python 写压测脚本。如果你团队里 Python 开发者多，Locust 的学习成本几乎为零。它的并发模型基于 gevent 协程，单机就能撑起上万并发，比 JMeter 的线程模型轻量得多。
不过，协程也有坑。我记得有一次压测一个长连接服务，Locust 的协程调度导致请求超时率异常高。排查后发现是 gevent 的 monkey-patch 和第三方库不兼容，折腾了大半天才找到替代方案。所以，用 Locust 之前，一定要确认你的依赖库和 gevent 兼容。
注意：Locust 的分布式模式依赖 master-slave 架构，但 master 节点容易成为瓶颈。我建议在 10 台以上 worker 时，考虑用消息队列做中间层，避免 master 过载。
Gatling：性能怪兽，但 Scala 门槛高
Gatling 是我个人比较偏爱的工具。它的底层基于 Akka Actor 模型，单机并发能力极强，而且天生支持异步非阻塞。用它压测 HTTP/2 和 WebSocket 时，效果比 JMeter 好一个量级。
但 Gatling 的脚本是用 Scala DSL 写的。说实话，Scala 的学习曲线确实陡。我团队里有个 Java 背景的同事，花了两周才写出第一个像样的压测脚本。如果你团队没有 Scala 基础，建议先用 JMeter 或 Locust 过渡，别一上来就上 Gatling。
另外，Gatling 的报表生成是一大亮点。它自动生成 HTML 报告，包含响应时间分布、吞吐量曲线、错误率等，比 JMeter 的默认报表好看得多。我经常直接用 Gatling 的报告给老板汇报，省了再画图的时间。
wrk：单机压测的瑞士军刀
wrk 是我做快速压测时的首选。它基于多线程 + epoll（Linux 下），单机就能压出几十万 QPS。而且安装简单，一条命令就能跑起来。适合做接口的基准测试、容量摸底。
但 wrk 的短板也很明显：只支持 HTTP/HTTPS，而且脚本能力弱（只能用 Lua 做简单定制）。我一般用它来做快速验证——比如上线前看看接口有没有性能回退，或者对比不同参数下的吞吐量。一旦需要复杂业务流程，我就换 JMeter 或 Gatling。
我的用法：wrk 配合 wrk2（带稳定速率模式），可以精确控制 QPS 发送速率，适合做容量测试和限流验证。命令示例：wrk -t12 -c400 -d30s --latency http://target
Vegeta：管道化压测的利器
Vegeta 和 wrk 类似，也是轻量级 HTTP 压测工具。但它有个独特优势：支持管道化（pipelining），可以在一个连接上连续发送多个请求，减少连接建立的开销。这在压测短连接服务时效果显著。
Vegeta 的用法也很简单，命令行 + JSON 格式的目标文件。我经常把它集成到 CI/CD 流水线里，每次部署后自动跑一轮压测，如果吞吐量下降超过阈值就告警。嗯，持续压测的最佳拍档。
不过，Vegeta 的报表功能比较弱，只有简单的文本输出。如果需要可视化，得自己写脚本解析结果。我一般配合 jq 和 gnuplot 来生成图表。
工具选型决策框架
说了这么多，到底怎么选？我总结了一个简单的决策框架，你可以照着这个思路来。
这个框架的核心逻辑是：先明确你的压测场景，再匹配工具特性。比如，你只是做接口的基准测试，wrk 或 Vegeta 就够用了，没必要上 JMeter 那一套重型工具。反过来，如果你要压测一个包含登录、下单、支付的全链路流程，JMeter 或 Gatling 才是正解。
我的经验：团队里最好同时维护 2-3 个工具。一个轻量级（wrk/Vegeta）做快速验证，一个重量级（JMeter/Gatling）做全链路压测，再备一个脚本灵活的（Locust）应对定制化需求。这样无论什么场景，你都有趁手的兵器。
小结
这一章我们聊了开源工具和商业工具的取舍，也逐个分析了 JMeter、Locust、Gatling、wrk、Vegeta 这五款工具的特点和适用场景。工具选型没有标准答案，但有一个原则不会变：让工具服务于场景，而不是让场景迁就工具。