第三章：测试工具选型——JMeter、Locust、wrk与ab的实战抉择

说实话，每次接手一个新项目，我最头疼的不是写脚本，而是选工具。你想想看，市面上压力测试工具少说几十种，光开源的就能列一长串。选错了，后面全是坑。我见过有人用wrk去测WebSocket长连接，结果折腾两天发现根本测不了——嗯，这就是典型的工具选型翻车现场。

这一章，我带你过一遍最主流的四款工具：JMeter、Locust、wrk、ab。我会结合自己的踩坑经历，告诉你每个工具到底适合什么场景。最后给出一张决策矩阵，帮你快速锁定答案。

3.1 JMeter核心概念——老牌劲旅，功能最全

JMeter是我用得最久的工具，没有之一。从2015年开始，我拿它测过电商、金融、物联网，几乎什么场景都碰过。它的核心优势就四个字：生态成熟。

3.1.1 核心组件

JMeter的架构其实不复杂，你只要搞懂这几个东西：

• 线程组（Thread Group）：模拟用户。每个线程就是一个虚拟用户。我习惯把线程数设成目标并发数，比如要测1000并发，就开1000个线程。
• 取样器（Sampler）：发请求。HTTP请求、JDBC请求、FTP请求……你想测什么协议，就选对应的取样器。
• 监听器（Listener）：看结果。聚合报告、图形结果、表格结果——我个人最常用的是“聚合报告”，因为它直接给出吞吐量、平均响应时间、错误率。
• 逻辑控制器（Logic Controller）：控制流程。比如循环控制器、随机控制器、如果（If）控制器。我在测登录流程时，经常用“如果控制器”来判断登录是否成功，再决定下一步。
• 配置元件（Config Element）：管理参数。CSV数据文件配置、HTTP请求默认值、用户定义的变量——这些能帮你把脚本写得干净利落。

3.1.2 参数化与关联

参数化说白了就是让每个虚拟用户用不同的数据。我常用的方式有两种：

• CSV数据文件配置：把用户名、密码、商品ID放在一个CSV文件里，JMeter会逐行读取。注意文件编码，我踩过UTF-8 BOM的坑，导致第一行数据读出来带乱码。
• 用户定义的变量：适合固定参数，比如服务器IP、端口号。我习惯把所有环境相关的参数都抽到这里，换环境时改一个地方就行。

关联就更关键了。比如你登录后拿到一个token，后面的请求都得带上它。JMeter里用正则表达式提取器或JSON提取器就能搞定。我个人更推荐JSON提取器，因为现在大部分接口返回的都是JSON格式，写起来更直观。

// 示例：从登录响应中提取token
// JSON提取器配置
变量名：token
JSON路径表达式：$.data.token
匹配编号：1

3.1.3 分布式压测

单机跑不了高并发怎么办？JMeter支持分布式。一台机器当Controller，多台机器当Agent。我曾在一次双十一压测中，用了20台Agent，每台跑500线程，总共模拟了10000并发。

但要注意：网络延迟和时间同步是两个大坑。Agent和Controller之间的网络延迟会影响结果准确性。我建议把所有机器放在同一个内网，并且用NTP服务同步时间。

3.2 Locust基础——Python党的最爱

Locust是我后来才接触的工具。说实话，第一次用的时候有点不习惯——它居然是用Python写脚本的。但用顺手之后，我发现它特别适合复杂业务逻辑的场景。

3.2.1 核心概念

Locust的核心就两个东西：

• User类：定义用户行为。你可以在里面写任意Python代码，比如if-else判断、循环、调用外部API。我曾在User类里集成了Redis客户端，用来验证缓存是否命中。
• Task装饰器：标记任务。@task(3)表示这个任务被执行的权重是3，@task(1)是1。权重越高，执行频率越高。我习惯把核心业务逻辑的权重设高一些。

from locust import HttpUser, task, between

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

3.2.2 优势与局限

Locust最大的优势是灵活。你想怎么模拟用户行为都行，因为底层就是Python。我曾在Locust脚本里调用了一个第三方OCR服务，用来模拟用户识别验证码——这在JMeter里几乎不可能实现。

但Locust也有短板：

• 协议支持有限：原生只支持HTTP/HTTPS。如果你想测WebSocket、gRPC，得自己写插件。我试过用gevent-websocket扩展，但稳定性一般。
• 结果展示较弱：Locust的Web UI虽然实时，但历史数据保存和对比功能不如JMeter。我一般会把结果导出到InfluxDB，再用Grafana画图。

3.3 wrk与ab对比——轻量级选手的较量

wrk和ab都是命令行工具，轻量、快速、适合快速验证。但它们的定位完全不同。

3.3.1 ab（Apache Bench）

ab是Apache自带的压测工具，安装Apache就会自带。它的用法极其简单：

ab -n 10000 -c 100 http://example.com/

这条命令的意思是：总共发10000个请求，并发100个。ab会输出吞吐量、平均响应时间、百分位响应时间。

但ab的缺点也很明显：

• 只支持HTTP/1.0和HTTP/1.1，不支持HTTP/2。我测过HTTP/2的接口，ab直接报错。
• 不支持动态参数。每个请求都一样，没法做参数化。如果你想模拟不同用户登录，ab做不到。
• 结果不够详细。ab只给出平均值和百分位，没有时间序列数据。你没法看到响应时间随时间的变化趋势。

3.3.2 wrk

wrk是更现代的工具，用C语言写的，性能极高。它的核心优势是多线程和Lua脚本支持。

wrk -t12 -c400 -d30s http://example.com/

这条命令的意思是：用12个线程，保持400个并发连接，持续压30秒。wrk的输出比ab更丰富，包括延迟分布、每秒请求数等。

wrk最强大的地方是Lua脚本。你可以用Lua写自定义逻辑，比如：

-- wrk脚本示例：模拟登录后访问首页
wrk.method = "POST"
wrk.body = '{"username":"test","password":"123456"}'
wrk.headers["Content-Type"] = "application/json"

response = function(status, headers, body)
    if status == 200 then
        -- 登录成功，提取token
        local token = headers["Authorization"]
        -- 后续请求带上token
        wrk.headers["Authorization"] = token
    end
end

但wrk的学习曲线比ab陡。你得会写Lua脚本，而且调试起来比较麻烦。我一般只在快速验证性能基线时用wrk，比如上线前跑一轮看看有没有性能退化。

3.3.3 对比总结

特性	ab	wrk
安装难度	极低（Apache自带）	低（需编译或包管理器）
协议支持	HTTP/1.0, HTTP/1.1	HTTP/1.1, HTTP/2（需编译）
动态参数	不支持	支持（Lua脚本）
结果详细度	低	中
适用场景	快速验证、简单接口	性能基线、简单业务逻辑

3.4 工具选型决策矩阵

说了这么多，到底怎么选？我整理了一张决策矩阵，你直接对着看就行。

场景	推荐工具	理由
快速验证接口性能	ab 或 wrk	轻量、快速、无需安装复杂环境
复杂业务逻辑（多步骤、条件分支）	Locust	Python脚本灵活，适合定制化场景
多协议支持（HTTP、JDBC、FTP等）	JMeter	生态最全，插件丰富
分布式压测（高并发）	JMeter	分布式方案成熟，社区支持好
团队全是Python工程师	Locust	降低学习成本，代码复用性高
需要详细报告和图表	JMeter	监听器丰富，可导出CSV/XML
持续集成（CI/CD）	JMeter 或 Locust	两者都支持命令行运行，可集成到Jenkins

3.5 本章知识体系图

下面这张SVG图，帮你把本章的核心逻辑串起来。从工具分类到选型决策，一目了然。

这张图的核心逻辑很简单：先看你的场景属于哪一类，再对号入座。轻量级工具适合快速验证，重量级工具适合复杂场景，脚本化工具适合定制需求，分布式方案解决高并发问题。

---

公众号:蓝海资料掘金营，微信deep3321