压测工具选型：JMeter vs Locust vs wrk vs ab
做性能压测这么多年，我经常被问到同一个问题：「到底该用哪个工具？」
说实话，没有银弹。每个工具都有自己的脾气。我见过有人用 ab 测复杂业务逻辑，结果测了个寂寞；也见过有人用 JMeter 测简单接口，光配置就花了两小时。
今天我把四个主流工具掰开揉碎讲清楚。你想想看，选工具就像选兵器——匕首有匕首的用法，青龙偃月刀有它的场合。
一、先看一张全景图
下面这张图是我自己整理的选型逻辑。每次带新人，我都先让他们看这个。
二、JMeter：老牌劲旅，功能全面
JMeter 是我用得最久的工具。说实话，它的 GUI 界面第一次看确实有点懵——满屏的元件、监听器、断言器。但用顺手了，你会发现它真的很能打。
核心优势：
- 支持多种协议：HTTP、HTTPS、JDBC、JMS、FTP……你能想到的它基本都支持
- 插件生态丰富：从图形报表到分布式压测，社区插件一应俱全
- 断言机制完善：响应断言、JSON断言、大小断言，想怎么验就怎么验
- 参数化灵活：CSV数据文件、函数助手、用户变量，数据驱动很方便
我记得有一次帮客户压测一个电商下单流程——登录、选商品、加购物车、下单、支付，五个接口串起来。用 JMeter 的「事务控制器」配合「正则提取器」，半小时就搭好了。换成其他工具，光写脚本就得半天。
但要注意：
- 资源消耗大：单机压 500 并发以上，JMeter 自己先喘上了
- 脚本维护麻烦：GUI 保存的 jmx 文件是 XML 格式，版本对比基本靠眼
- 学习曲线陡：新手容易在「监听器」和「配置元件」之间迷失
我的建议：如果你要压测复杂的业务流程，或者团队里测试人员不擅长写代码，JMeter 是首选。但记得压测时关掉所有监听器，用命令行模式跑——不然结果会失真。
三、Locust：Python 党的最爱
Locust 是我后来才接触的。第一次用的时候，我心想：这不就是写个 Python 脚本吗？结果一试，真香。
它的核心思想很简单：你写一个 Python 类，定义用户行为，然后 Locust 用协程帮你模拟成千上万个用户。代码即脚本，脚本即配置。
from locust import HttpUser, task, between
class WebsiteUser(HttpUser):
wait_time = between(1, 5)
@task(3)
def view_home(self):
self.client.get("/")
@task(1)
def search(self):
self.client.get("/search?q=test")你看，就这么几行代码，一个压测脚本就写好了。想加登录？加个 on_start 方法就行。想做数据校验？直接用 Python 的 assert。
核心优势：
- 纯 Python 编写，可读性强，版本控制友好
- 协程并发，单机可以模拟上万用户
- Web UI 实时查看结果，支持分布式
- 自定义能力强：想怎么模拟用户行为都行
我曾经在一个项目中，需要模拟用户先登录、然后随机浏览商品、最后下单。用 Locust 写了个 UserBehavior 类，配合 random.choice 控制行为概率，整个脚本不到 100 行。团队里其他同事一看就懂，改起来也方便。
但要注意：
- 依赖 Python 生态：Python 版本、第三方库版本都要管理好
- 报告功能相对弱：默认的 Web UI 只能看实时数据，历史对比需要自己写
- 对非 HTTP 协议支持有限：虽然可以扩展，但不如 JMeter 方便
四、wrk：轻量级高并发利器
wrk 是我做「快速摸底」时的首选。它用 C 语言写的，底层用多线程 + epoll/kqueue，单机压个几万 QPS 轻轻松松。
用法也简单到令人发指：
wrk -t12 -c400 -d30s http://example.com这条命令的意思是：12 个线程，400 个并发连接，压 30 秒。结果直接打印在终端上——延迟分布、吞吐量、错误率，一目了然。
核心优势：
- 性能极高：C 语言实现，几乎没有额外开销
- 使用简单：一条命令搞定，适合快速验证
- 支持 Lua 脚本：可以做一些简单的请求定制
- 结果清晰：直接输出 P50/P75/P99 延迟
我记得有一次线上告警，说接口响应变慢了。我二话不说，先跑了个 wrk 看看基线——发现 P99 延迟从 50ms 飙到了 500ms。然后才去排查代码。wrk 帮我快速锁定了「是性能退化，不是偶发抖动」。
但要注意：
- 只支持 HTTP/HTTPS 协议
- 不支持复杂的业务逻辑：比如登录态、参数关联
- 结果报告比较简陋：没有图表，没有历史对比
- Windows 上安装麻烦：需要编译或者用 WSL
五、ab：最古老的压测工具
ab（Apache Bench）是 Apache 自带的压测工具。说实话，现在用得越来越少了。但它的存在价值在于——几乎所有 Linux 系统都自带。
ab -n 10000 -c 100 http://example.com/这条命令：总共发 10000 个请求，并发 100 个。结果会告诉你每秒请求数、平均延迟、传输速率。
核心优势：
- 零安装：Apache 自带，或者 apt-get install 一下就行
- 极简：一条命令跑完，适合临时验证
- 结果稳定：这么多年了，bug 很少
我曾经在客户现场，服务器上啥工具都没有，网络也不通。我直接 apt-get install apache2-utils，装完就跑 ab，5 分钟给出了初步结论。这种场景下，ab 就是救命稻草。
但要注意：
- 功能极其单一：不支持 Cookie、不支持 POST 请求体定制（很麻烦）
- 单机并发能力有限：超过 1000 并发，ab 自己先扛不住
- 结果信息少：没有延迟分布，只有平均值
- 已停止维护：Apache 官方基本不更新了
六、选型建议：到底怎么选？
| 场景 | 推荐工具 | 理由 |
|---|---|---|
| 复杂业务流程压测 | JMeter | GUI配置方便，断言和参数化完善 |
| 自定义场景、团队懂Python | Locust | 代码即脚本，灵活度高 |
| 纯接口高并发摸底 | wrk | 性能极高，结果清晰 |
| 临时快速验证 | ab | 零安装，一条命令搞定 |
| 分布式压测 | JMeter / Locust | 两者都支持分布式部署 |
我个人习惯：
日常工作中，我一般这样搭配：
- 开发自测、快速摸底 → wrk
- 接口级压测、回归验证 → Locust（脚本放 Git 里，方便团队协作）
- 全链路压测、复杂场景 → JMeter
- 服务器上临时验证 → ab
你想想看，工具是死的，人是活的。关键不是「哪个工具最好」，而是「哪个工具最适合你当前的场景」。
七、避坑指南
最后分享几个我踩过的坑：
- 我曾经用 JMeter 压测时没关监听器，结果压测机 CPU 100%，吞吐量数据严重偏低。后来才知道，监听器本身也在消耗资源。压测时一定要用命令行模式：
jmeter -n -t script.jmx -l result.jtl - 我曾经用 wrk 压测带登录态的接口，结果 wrk 不支持 Cookie 自动管理。后来用 Lua 脚本手动处理了 Cookie，才搞定。
- 我曾经用 ab 压测 POST 接口，结果发现 ab 的 POST 数据格式很坑。后来改用
-p参数指定文件，才勉强能用。 - Locust 的协程模式虽然并发高，但如果你的业务代码里有阻塞操作（比如同步数据库查询），协程的优势就没了。记得用异步库。
嗯，工具选型就讲到这里。记住一句话：没有最好的工具，只有最合适的工具。选对了工具，压测就成功了一半。