3. 工具选型：JMeter vs Locust vs wrk vs ab

说实话，每次有新人问我「压测该用哪个工具」，我都挺头疼的。因为这个问题没有标准答案。我见过有人用 ab 测了一整年的接口，也见过团队用 JMeter 搭了全套的 CI 压测流水线。

工具选型这件事，说白了就是「看人下菜碟」。你的团队技术栈是什么？被测系统的协议是什么？你要压的是单接口还是全链路？这些因素直接决定了该选谁。

今天我就把这四个主流工具掰开揉碎了讲。我会结合自己踩过的坑，帮你理清思路。

3.1 先看一张全景图

在深入每个工具之前，我习惯先画一张图，把它们的定位看清楚。这样你心里就有谱了。

这张图我画了好几个版本，最终选了这种四象限的布局。你看，横轴是功能复杂度，纵轴是性能要求。JMeter 在右上角，功能最强但性能开销也大；ab 在左下角，简单粗暴但够用。

3.2 JMeter：压测界的瑞士军刀

JMeter 是我用得最多的工具，没有之一。为什么？因为它什么都能干。HTTP、HTTPS、WebSocket、JDBC、JMS、gRPC……你能想到的协议，它基本都支持。

我记得有一次帮一个金融客户做全链路压测，从网关到业务服务，再到数据库和消息队列，整个链路涉及 6 个系统。用 JMeter 的线程组 + 逻辑控制器 + 监听器，我硬是把整个流程串了起来。最后还生成了带聚合报告和图表。

  核心优势：
  图形化界面，拖拽式配置，上手快
插件生态丰富（Redis、Kafka、MongoDB 等）
支持分布式压测，可以横向扩展
结果报告非常详细，适合做性能分析

注意坑点：

JMeter 本身是用 Java 写的，跑起来挺吃内存。我曾经在 8G 的笔记本上开 500 个线程，结果 GUI 直接卡死。后来学乖了，压测时用命令行模式（jmeter -n -t），GUI 只用来调试脚本。

另外，JMeter 的脚本是 XML 格式的，多人协作时 diff 起来很痛苦。我建议用 Git 管理时，配合 JMeter 的「保存为测试片段」功能，把公共部分抽出来。

我的建议：

如果你的团队有专职的性能测试人员，或者被测系统涉及多种协议，选 JMeter 准没错。但如果你只是开发同学临时压一下接口，它可能有点重了。

3.3 Locust：开发者的压测利器

Locust 是我个人很喜欢的一个工具。它的核心理念是「用代码定义用户行为」。你写一段 Python 脚本，描述用户怎么登录、怎么浏览、怎么下单，然后 Locust 会模拟成千上万个这样的用户。

为什么说它适合开发者？因为 Python 脚本本身就是代码，你可以用 if/else、循环、函数、类，甚至引入第三方库。我曾在 Locust 脚本里接入了 Faker 库来生成随机数据，还用了 Redis 做分布式计数器。

# 一个简单的 Locust 脚本示例
from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 5)  # 用户等待时间 1-5 秒
    
    @task(3)  # 权重 3
    def view_homepage(self):
        self.client.get("/")
    
    @task(1)  # 权重 1
    def login(self):
        self.client.post("/login", json={
            "username": "test_user",
            "password": "123456"
        })

  核心优势：
  纯 Python 编写，灵活度极高
Web UI 实时查看压测进度
支持分布式，每个 worker 是一个进程
与 CI/CD 集成方便（命令行模式）

注意坑点：

Locust 的并发模型是基于协程（gevent）的，不是真正的多线程。这意味着如果你的被测服务有同步阻塞操作，Locust 的模拟可能不够真实。我曾经压一个老旧的同步服务，Locust 跑出来的 TPS 比实际高 30%，后来换 JMeter 才复现了真实情况。

另外，Locust 的报告功能比较弱，没有 JMeter 那么详细的聚合数据。我一般会配合 InfluxDB + Grafana 来收集和展示结果。

我的建议：

如果你的团队以 Python 为主，或者你需要模拟复杂的用户行为（比如电商下单流程），Locust 是很好的选择。但如果你需要详细的性能分析报告，建议搭配其他工具使用。

3.4 wrk：极简主义的高性能压测

wrk 是我压测单接口时的首选。它是一个用 C 语言写的命令行工具，体积小、性能高。你给它一个 URL，指定并发数和持续时间，它就能跑出漂亮的报告。

我记得有一次线上出了性能问题，需要快速验证一个优化方案是否有效。我直接在服务器上装了 wrk，一条命令跑完，前后不到 30 秒就拿到了结果。这种「秒级反馈」的感觉，JMeter 和 Locust 都给不了。

# wrk 基本用法
wrk -t12 -c400 -d30s http://example.com/api

# 参数说明：
# -t12: 12 个线程
# -c400: 400 个并发连接
# -d30s: 持续 30 秒

  核心优势：
  性能极高，单机可压出数万 QPS
安装简单，一条命令搞定
输出简洁，延迟分布一目了然
支持 Lua 脚本，可自定义请求

注意坑点：

wrk 只支持 HTTP/HTTPS 协议，不支持 WebSocket、gRPC 等。而且它没有 GUI，所有配置都得通过命令行参数和 Lua 脚本。如果你需要复杂的场景编排，wrk 会显得力不从心。

另外，wrk 的 Lua 脚本能力有限，不能做太复杂的逻辑。我试过在 Lua 里做用户登录和 token 管理，写起来非常痛苦。

我的建议：

wrk 适合「快速验证」场景。比如你改了一个数据库索引，想知道 QPS 提升了多少；或者你想对比两个服务的性能差异。这时候 wrk 是最趁手的工具。

3.5 ab：Apache 自带的轻量级选手

ab（Apache Bench）是 Apache HTTP Server 自带的压测工具。它比 wrk 还要简单，甚至不需要安装——如果你装了 Apache，ab 就在那里等着你。

我最早接触压测就是用的 ab。那时候刚入行，领导让我测一下新上线的接口能抗多少并发。我打开终端，敲了一行命令，看着屏幕上刷刷刷滚动的结果，感觉特别酷。

# ab 基本用法
ab -n 10000 -c 100 http://example.com/api

# 参数说明：
# -n 10000: 总共 10000 个请求
# -c 100: 并发 100 个请求

  核心优势：
  零安装，Apache 自带
命令极简，参数少，学习成本低
输出包含关键指标（TPS、延迟、失败率）
适合快速摸底

注意坑点：

ab 的功能太单一了。它只能压 HTTP/HTTPS，不支持 POST 请求体中的复杂参数（虽然可以用 -p 指定文件，但很麻烦）。而且它不支持 Cookie 管理、Session 保持、动态参数等。

另外，ab 的并发模型是 fork 子进程，在高并发下性能不如 wrk。我曾经用 ab 压 1000 并发，结果 ab 自己先扛不住了，CPU 跑到 100%。

我的建议：

ab 适合「临时起意」的压测。比如你在开发环境想看看接口大概能抗多少，或者你只是想验证一下服务有没有启动成功。但正式的性能测试，我建议还是用 wrk 或 JMeter。

3.6 选型决策矩阵

说了这么多，到底该怎么选？我整理了一个表格，你对照自己的场景看就行。

场景	推荐工具	理由
全链路压测（多协议、多系统）	JMeter	协议支持最全，场景编排能力强
开发团队自测（Python 技术栈）	Locust	代码灵活，与 CI/CD 集成方便
单接口高并发压测	wrk	性能极高，秒级反馈
快速摸底、临时验证	ab	零安装，命令简单
需要详细报告和图表	JMeter + 插件	报告功能最完善
需要自定义用户行为	Locust	Python 脚本，灵活度最高

嗯，这个表格基本覆盖了大部分场景。但我想强调一点：工具只是手段，不是目的。我见过有人用 JMeter 压一个简单的 GET 接口，折腾了半天脚本；也见过有人用 ab 压全链路，结果漏掉了关键的业务逻辑。

选工具之前，先想清楚你要测什么、怎么测、结果怎么用。想清楚了，工具自然就选出来了。

最后说一句：

不要迷信任何一个工具。我自己的工具箱里，JMeter、Locust、wrk、ab 都有。不同的场景换不同的工具，这才是老司机的做法。

📚 课程目录

3. 工具选型：JMeter vs Locust vs wrk vs ab

3.1 先看一张全景图

3.2 JMeter：压测界的瑞士军刀

3.3 Locust：开发者的压测利器

3.4 wrk：极简主义的高性能压测

3.5 ab：Apache 自带的轻量级选手

3.6 选型决策矩阵