性能测试工具对比：JMeter、LoadRunner、Locust、Gatling
做性能测试，选对工具能省一半的力气。我在这个行业摸爬滚打了十几年，见过太多人花大量时间折腾工具本身，而不是真正去分析瓶颈。今天就拿市面上最主流的四款工具——JMeter、LoadRunner、Locust、Gatling——做个硬核对比。不说废话，直接上干货。
先说结论：没有银弹，只有最合适的
这四款工具，各有各的脾气。说白了，选哪个取决于你的团队技术栈、项目规模和预算。
- 团队全是 Java 背景，公司不差钱？ → LoadRunner 的企业级支持会让你省心。
- 你们用微服务、K8s，想和 CI/CD 流水线无缝集成？ → Gatling 是首选，Scala 写脚本，性能报表漂亮得不像话。
- 团队 Python 技术栈，喜欢灵活可控？ → Locust 会让你感觉亲切，协程并发模型很轻量。
- 想找一款免费、社区庞大、啥都能测的万金油？ → JMeter，没有之一。
嗯，先有个大概印象。下面一个个细说。
Apache JMeter：老牌王者，但有点“重”
JMeter 是我用得最多的工具，没有之一。它的插件生态太丰富了，几乎你能想到的协议它都支持：HTTP、JDBC、JMS、FTP……而且 GUI 界面，新手也能快速上手。
核心优势：
- 纯 Java 实现，跨平台。
- 插件管理器，扩展能力强。
- 分布式压测方案成熟。
避坑指南：
我曾经在压测一个高并发秒杀接口时，发现 JMeter 自身成了瓶颈。原因是我在 GUI 模式下运行了太久——记住，压测一定要用 jmeter -n -t script.jmx -l result.jtl 命令行模式！GUI 模式是调试用的，不是压测用的。
JMeter 的脚本是 XML 格式，一旦测试复杂起来，文件会变得又大又难维护。我个人习惯是把参数化、断言这些逻辑用 JSR223 预处理器配合 Groovy 脚本写，比用 GUI 配置灵活得多。
Micro Focus LoadRunner：企业级重型武器
LoadRunner 是商业工具的标杆，贵，但真香。它的协议支持是业界最全的，尤其是 SAP、Oracle EBS、Citrix 这些企业级应用，JMeter 很难模拟，LoadRunner 却能做到。
它最大的特色是 VuGen（虚拟用户生成器）和 Controller（场景控制器）。录制回放功能很强，对测试脚本工程师要求不高。但想用好它，得花功夫学 C 语言或者 Java Vuser 脚本。
我的经验：
如果你的项目需要严格遵循某些行业标准（如金融、通信），或者是做高负载的并发用户测试，LoadRunner 的精确控制能力是无与伦比的。比如，你可以精确控制每秒新增多少个用户，这点 JMeter 的线程组很难做到平滑递增。
我曾经踩过的坑：
有一次用 LoadRunner 压测，因为 Controller 和 Agent 之间的防火墙没配置好，导致大量虚拟用户无法注册。排查了很久才发现是端口被拦了。所以，网络通信基础一定要扎实。
Locust：Python 玩家的利器
如果你喜欢 Python，那 Locust 会让你爱不释手。它使用纯 Python 写测试脚本，没有臃肿的 XML，没有复杂的配置。你写的测试代码，本质上就是一个“入侵”系统的客户端。
它的核心是 协程（gevent） 并发模型，所以单机并发能力比 JMeter 的线程模型强出不少。我记得有一次压测一个 WebSocket 服务，JMeter 开到 2000 线程就报 OOM 了，Locust 跑 5000 协程还能稳稳的。
from locust import HttpUser, task, between
class WebsiteUser(HttpUser):
wait_time = between(1, 5)
@task
def index_page(self):
self.client.get("/")
但是，Locust 的报表功能比较朴素，没有 Gatling 那种“高颜值”的 HTML 报告。而且它的分布式压测方案，需要自己管理 Worker 节点，不像 JMeter 有集成好的插件。
适用场景：
- 快速原型验证。
- 需要和 Python 生态（如 AI、数据处理）结合的测试。
- 简单 HTTP API 性能测试。
Gatling：为高并发而生的代码契约
Gatling 是一个基于 Akka 和 Netty 的工具，用 Scala 写脚本。它的最大卖点：性能报表太漂亮了。响应时间分布图、每秒请求数（RPS）曲线、百分位线，都集成在一个精美的 HTML 报告中。
而且，Gatling 的架构设计天生适合做高并发压力。我记得有一次帮一家电商公司做“双十一”预演，用 Gatling 跑了 10 万 QPS 的混合场景，稳定性非常出色，资源占用也比 JMeter 低 40% 左右。
class BasicSimulation extends Simulation {
val httpProtocol = http.baseUrl("http://computer-database.gatling.io")
val scn = scenario("BasicSimulation")
.exec(http("request_home").get("/"))
.pause(5)
setUp(
scn.inject(atOnceUsers(100))
).protocols(httpProtocol)
}
注意：
Gatling 的学习曲线稍微陡峭。如果你的团队没有 Scala 基础，维护脚本的成本会比较高。我见过有团队硬着头皮用 Gatling，结果每次改脚本都像在写新项目。
横评对比：一张表说清楚
| 特性 | JMeter | LoadRunner | Locust | Gatling |
|---|---|---|---|---|
| 协议支持 | 极广（插件） | 最广（商业） | 仅 HTTP/WebSocket | HTTP/JMS/WebSocket |
| 脚本语言 | Groovy/Java | C/Java/VBScript | Python | Scala/Java |
| 学习曲线 | 中等 | 高 | 低 | 中高（需 Scala） |
| 单机并发能力 | 一般（线程模型） | 优秀（进程驱动） | 强（协程） | 极强（Actor 模型） |
| 报表质量 | 中等（需插件） | 强大（企业级） | 简陋 | 一流 |
| CI/CD 集成 | Maven/Gradle 插件 | 企业组件 | 命令行 | Maven/sbt 原生 |
| 价格 | 免费 | 高（按 vUser 授权） | 免费 | 免费（开源） |
怎么选？我给你搭个决策树
你想想看，如果今天你接手一个全新的性能测试任务，你该怎么选？我一般是这样判断的：
- 先看预算： 有钱任性？LoadRunner 走起，省心。预算有限？JMeter 或 Gatling。
- 再看团队技术栈： 全员 Java 背景？JMeter 或 Gatling。全是 Python 仔？Locust 更匹配。
- 最后看场景： 简单的 HTTP 测试？四个工具都能干，选你最顺手的。复杂的多协议、企业级应用？LoadRunner 或 JMeter。
我的推荐组合：
我个人习惯是：日常小压测用 Locust，快速验证。正式性能回归和压力测试用 Gatling，拿漂亮的报表去说服领导。如果客户有特殊协议要求，再上 JMeter 或者 LoadRunner。
补充三个避坑经验
最后，我再分享三个我亲自踩过的坑：
- 别用 GUI 压测。 不管什么工具，正式压测一定走命令行或 CI 集成。GUI 会吃掉大量系统资源，导致你测的不是应用，而是压测工具本身。
- 参数化要小心。 我在做 Locust 压测时，曾经因为参数化数据生成太慢，导致协程大部分时间都在等待参数，压测结果完全失真。后来我换成了预生成 ID 池，效率提升 10 倍。
- 监控不能省。 你压测时看到的响应时间飙升，到底是因为应用服务器 CPU 满了，还是网络带宽打满了？没有全链路监控（如 Prometheus + Grafana），你只能猜。我建议压测前先部署好节点监控和 APM 工具。
嗯，这四款工具对比到这里就差不多了。选工具不难，难的是用好它，理解它背后的原理。接下来的章节，我会带你一步步搭建一个完整的 JMeter 压测脚本，并手把手教你分析性能报告。别急，慢慢来。