3. 性能测试工具选型：主流工具对比与实战场景

性能测试工具那么多，怎么选？说实话，我见过不少团队一上来就抱着JMeter不放，结果测短连接压到一半自己先挂了；也有人迷信wrk有多快，结果连HTTP Keep-Alive都没搞清楚。工具选型这事儿，没有银弹，关键得看你测什么、在什么环境下测、团队什么水平。

这一节我把市面上最常用的几款工具拉出来对比——JMeter、LoadRunner、wrk、ab、Locust、vegeta。不会只讲参数，我会结合自己踩过的坑，告诉你什么场景该用谁、不该用谁。

3.1 工具速览与定位

按使用场景，我习惯把这6个工具分成三组：

• 图形界面重型选手：JMeter、LoadRunner——适合复杂测试场景、多协议、需要报告审核的团队。
• 命令行单机压测小钢炮：wrk、ab——适合快速验证、压力测试毛估估、本地开发调试。
• 编程扩展派：Locust、vegeta——适合需要灵活控制流量模型、融入CI/CD管线的团队。

先看一张整体的对比结构图，后面再逐项展开。

3.2 逐个拆解：特点、用法与坑

3.2.1 JMeter —— 全能但笨重

JMeter是开源工具里的老大哥。支持HTTP、HTTPS、JDBC、JMS、FTP、SOAP、REST……你想得到的协议它基本都支持。而且有图形界面，可以录制回放，团队协作时脚本可读性较高。

适用场景：需要验证复杂业务链路（比如下单→支付→取消→退款）的场景，或者需要生成多种报告供评审的团队。

我遇到的坑：JMeter默认的Java堆栈只有512MB。曾经一次压测，跑到一半控制台卡死，最后发现GC占用了70%的CPU。后来硬着头皮把 -Xms -Xmx 调到4GB才算稳住。另外JMeter分布式压测时，Agent和Controller之间的同步机制在并发数大时会丢数据，我们被迫加了一层本地日志回传。

3.2.2 LoadRunner —— 企业级但贵

LoadRunner是Micro Focus的商业产品。说实话如果不是公司采购了，我个人不会自己掏钱用它。它的优势在于：

• 对多种企业级协议（如Citrix、SAP GUI、Oracle Forms）支持极好
• 内置强大的监控与分析模块，可以关联服务器资源、数据库、中间件指标
• 报告自动化程度高，适合合规性测试

但缺点也很明显：价格昂贵、学习曲线陡、脚本用C语言（VuGen），团队里Java/Python背景的工程师改起来痛苦。我参与过一个金融项目，客户指定用LoadRunner，结果光培训成本就花了整个项目周期的1/5。

3.2.3 wrk —— 单机压测之王

wrk是我个人最常用的快速压测工具。它基于C语言和Reactor模式，多线程 + 非阻塞I/O，单机轻松打满万兆网卡。用法简单到发指：

# 压测一个HTTP API，持续30秒，12个线程，400个连接
wrk -t12 -c400 -d30s http://api.example.com/login

亮点：可以用Lua自定义请求构造、参数化、校验响应。比如我压测一个带签名的接口，就写个Lua脚本每次生成新的签名header。

-- 示例：wrk Lua脚本，给每个请求加一个随机时间戳
counter = 0
function request()
    counter = counter + 1
    local path = "/api?ts=" .. os.time() .. "&seq=" .. counter
    return wrk.format("GET", path)
end

缺点：只支持单机，不支持分布式；报告极其简洁，只有吞吐、延迟百分位、错误数；无法模拟复杂业务流（比如多个API串联）。

3.2.4 ab (Apache Bench) —— 极简但有限

ab是Apache自带的压测工具。我第一次用是在大学，以为压测就是ab。现在回头看，ab只适合验证“一个URL能不能正常返回”这种最基础的需求。

# 发送10000个请求，并发100个
ab -n 10000 -c 100 http://example.com/

ab有个致命问题：它不支持HTTP Keep-Alive的持久连接复用。也就是说每个请求都要经历TCP三次握手，大多数压测场景下这会导致cpu开销大头在系统调用上，而不是真正测量业务处理时间。另外它只能压测单一URL，无法做参数化或动态URL。

3.2.5 Locust —— Python工程师的最爱

Locust用Python写测试脚本，天生对做后端的同学友好。定义用户行为就像写一个类：

from locust import HttpUser, task, between

class MyUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def index(self):
        self.client.get("/")

    @task(3)
    def about(self):
        self.client.get("/about")

优势：可以非常精细地控制用户行为、权重、等待时间。分布式压测开箱即用——启动一个master，n个worker即可。Web UI实时显示RPS、响应时间、错误率，不会写前端也能看。

劣势：性能不如C/Go写的工具。Locust每个用户是一个greenlet，当并发数超过几千时，Python解释器本身的开销就非常明显。我试过压测纯静态页面，单机最多跑到1万RPS左右，而wrk可以轻松到10万+。

3.2.6 vegeta —— 集成CI/CD的首选

vegeta是Go写的，理念很纯粹——只做攻击（压测）和报告生成，没有花哨的GUI。所有操作通过命令行和管道完成，天然适合脚本化。

# 准备一个目标文件 targets.txt
echo "GET http://api.example.com/health" | vegeta attack -rate=1000 -duration=30s | vegeta report

vegeta可以输出JSON格式的详细报告，方便对接Grafana或者自定义告警。我曾在CI流水线里把vegeta作为性能回归测试的一部分——每次合并代码后自动压测，如果P99延迟比基线高出20%则阻塞流水线。

vegeta的缺点：没有用户行为概念，只能做“恒定压力”或“给定速率”的攻击，不适合模拟随机思考时间的用户行为。不过这在很多场景下反而是优点——简单、可复现、没有噪音。

3.3 核心对比表格

维度	JMeter	LoadRunner	wrk	ab	Locust	vegeta
开源/商业	开源	商业	开源	开源	开源	开源
脚本语言	Java/BeanShell	C语言	Lua（可选）	命令行参数	Python	Go/Shell管道
最大并发能力	中等（依赖GC）	高（需要调优）	极高	低	中等（GIL限制）	高
多协议支持	非常多	非常多	仅HTTP	仅HTTP	HTTP为主，可扩展	仅HTTP
分布式	支持（需调优）	支持（内置）	不支持	不支持	支持（原生）	不支持但可脚本组合
报告能力	丰富（各类图表）	极强	简单（命令行）	极简单	Web UI + 可导出	文本/JSON
CI/CD集成	一般（需要插件）	差	容易（命令行）	容易（命令行）	容易（无头模式）	极容易
学习成本	中等	高	低	极低	低	低

3.4 选型决策流程

我一般这样帮团队做选择：

1. 先问协议：如果被测系统不是HTTP（比如WebSocket、gRPC、MQTT、数据库直连），直接锁定JMeter或LoadRunner。
2. 再问场景复杂度：如果是一个串行业务流，需要登录→查询→下单→支付，而且需要断言每个步骤的状态码和响应体，选JMeter。
3. 再问压测目的是什么：
• 只是想看接口能扛多少并发？直接用wrk或vegeta。
• 需要模拟真实用户思考时间、权重？Locust适合你。
• 只是开发阶段快速验证？ab就够了，但记住不要用它的结果定规格。
4. 最后问团队偏好：全栈团队习惯Python，别逼他们写Java/JMeter。运维团队用wrk可能上手更快。

3.5 小结