2. 压测工具选型
做性能压测这么多年,我经常被问到同一个问题:「到底该用哪个工具?」
说实话,没有银弹。每个工具都有自己的脾气。你想想看,用菜刀切西瓜和用水果刀削苹果,能是一回事吗?
今天我就把这几个主流工具掰开揉碎了讲。我踩过的坑,你就不用再踩了。
核心观点:选工具不是选最火的,而是选最合适的。你的业务场景、团队技术栈、预算,这三个因素决定了最终答案。
1. JMeter:全能型选手,但有点重
JMeter 是我用得最多的工具,没有之一。它最大的优点是生态丰富。从 HTTP、JDBC 到 JMS,几乎你能想到的协议它都支持。
我记得有一次帮一家金融公司做压测,他们的系统用了自定义的 TCP 协议。换成别的工具,估计得从头写插件。但 JMeter 有现成的 TCP Sampler,改改配置就能用。嗯,这就是生态的力量。
| 优点 | 缺点 |
|---|---|
| 支持协议多(HTTP/HTTPS/WebSocket/JDBC 等) | GUI 模式压测时资源消耗大 |
| 社区活跃,插件丰富 | 脚本编写相对复杂,学习曲线陡 |
| 支持分布式压测 | 报告生成需要额外配置(如 InfluxDB + Grafana) |
| 免费开源,跨平台 | 单机并发量有限(一般建议不超过 1000 线程) |
我的建议:如果你需要做复杂的业务场景模拟,或者团队里测试人员偏多,JMeter 是首选。但记住,生产级压测一定要用 CLI 模式,别开 GUI。
2. LoadRunner:企业级老大哥,但贵
LoadRunner 是我刚入行时接触的第一个工具。说实话,它确实强大,但也是真的贵。一套 License 下来,够小公司吃半年了。
它的优势在于协议支持极其全面,尤其是那些老旧的 ERP、CRM 系统。我有个朋友在一家银行做测试,他们的核心系统只认 LoadRunner 的 Citrix 协议,别的工具根本连不上。
| 优点 | 缺点 |
|---|---|
| 协议支持最全面(包括 Citrix、SAP、Oracle Forms 等) | 价格昂贵,License 按虚拟用户数收费 |
| 自带强大的分析器(Analysis) | 安装配置复杂,环境依赖多 |
| 支持大规模分布式压测 | 社区资源相对封闭,遇到问题难找答案 |
| 企业级支持和服务 | 脚本语言(C/Vuser)学习成本高 |
避坑指南:我曾经帮一家公司评估 LoadRunner 迁移方案。他们每年花 50 万买 License,但实际只用到了 HTTP 协议。说白了,这就是典型的「杀鸡用牛刀」。如果你的场景不涉及那些冷门协议,真没必要上 LoadRunner。
3. wrk:轻量级利器,适合快速验证
wrk 是我个人非常喜欢的一个工具。它有多轻?一个可执行文件,几 KB 大小,解压就能用。而且它基于 Reactor 模式,用少量的线程就能模拟大量并发连接。
我经常用它来做快速摸底。比如新上线一个接口,我想看看它的极限 QPS 是多少。用 wrk 写个 Lua 脚本,几秒钟就能跑出结果。
# 一个简单的 wrk 压测命令
wrk -t12 -c400 -d30s --latency http://localhost:8080/api/test
| 优点 | 缺点 |
|---|---|
| 极轻量,无依赖,开箱即用 | 只支持 HTTP/HTTPS 协议 |
| 性能极高,单机可模拟数万并发 | 不支持复杂的业务逻辑(如登录、参数化) |
| 内置 Lua 脚本扩展,可定制请求 | 报告功能弱,需要自己解析输出 |
| 延迟统计精确(内置毫秒级 Latency) | 不支持分布式压测 |
我的用法:wrk 适合「开发自测」和「快速定位瓶颈」。比如你改了个配置,想知道性能有没有提升,用 wrk 跑两轮对比一下,结果一目了然。但别用它做复杂的全链路压测,那是 JMeter 的活。
4. ab:最古老的压测工具,简单粗暴
ab(Apache Bench)是 Apache 自带的压测工具。说实话,它现在用得越来越少了。但为什么我还要提它?因为它足够简单。
我记得刚入行时,领导让我测一下 Nginx 的并发能力。我二话不说装了个 JMeter,折腾了半天。旁边的老同事看了一眼,直接在终端敲了一行 ab 命令,10 秒出结果。嗯,那一刻我明白了什么叫「够用就好」。
# ab 的基本用法
ab -n 10000 -c 100 http://localhost:8080/
| 优点 | 缺点 |
|---|---|
| 最简单,一行命令搞定 | 只支持 HTTP/HTTPS(且不支持 HTTPS 的某些高级特性) |
| 几乎所有 Linux 系统预装 | 不支持 Keep-Alive 的精细控制 |
| 结果输出清晰,包含吞吐量、延迟、失败率 | 单机并发能力有限(一般不超过 1000) |
| 无任何依赖 | 不支持动态参数、Cookie、Session |
注意:ab 的并发模型是「多进程 + 多线程」,在高并发下资源消耗很大。我曾经用 ab 压测一个简单的静态页面,并发设到 2000,结果压测机自己先挂了。所以,ab 只适合做低并发、简单场景的快速验证。
5. Locust:Python 玩家的最爱,灵活但性能一般
Locust 是这几年比较火的一个工具。它的核心卖点是用 Python 写压测脚本。如果你团队里都是 Python 开发者,那 Locust 简直是天选之子。
我有个朋友在游戏公司做测试,他们的业务逻辑极其复杂——登录、选角色、进副本、打怪、掉装备,每一步都有状态依赖。用 JMeter 写这种脚本,得配一堆 If Controller 和正则提取器,累死人。但用 Locust,直接写 Python 代码,想怎么控制就怎么控制。
# Locust 脚本示例
from locust import HttpUser, task, between
class WebsiteUser(HttpUser):
wait_time = between(1, 5)
@task
def index_page(self):
self.client.get("/")
@task(3)
def view_item(self):
self.client.get("/item?id=123")
| 优点 | 缺点 |
|---|---|
| 脚本灵活,Python 代码控制一切 | 单机并发性能一般(受限于 Python GIL) |
| Web UI 实时监控,结果直观 | 协议支持有限(主要 HTTP/WebSocket) |
| 支持分布式压测(Master-Slave 模式) | 分布式部署配置较复杂 |
| 开源免费,社区活跃 | 报告功能弱,需要二次开发 |
我的建议:如果你的压测场景需要复杂的业务逻辑控制(比如状态机、条件分支),而且团队熟悉 Python,那 Locust 是很好的选择。但如果你追求极致性能,比如单机压到 10 万 QPS,那还是用 wrk 或者 JMeter 的 CLI 模式吧。
核心对比:一张图看懂
说了这么多,我画了一张对比图,帮你快速决策:
最终建议:怎么选?
说了这么多,我总结一下我的个人经验:
- 如果你是开发,想快速验证接口性能 → 用 wrk 或 ab。5 分钟上手,10 秒出结果。
- 如果你是测试,要做全链路压测 → 用 JMeter。生态好,社区强,遇到问题容易找到答案。
- 如果你在银行、保险等传统行业 → 考虑 LoadRunner。虽然贵,但那些冷门协议只有它能搞定。
- 如果你团队全是 Python 开发者 → 用 Locust。写脚本就像写业务代码一样自然。
最后说一句:工具只是手段,不是目的。我见过有人用 ab 跑出了 10 万 QPS,也见过有人用 JMeter 连 1000 并发都跑不稳。关键不在于工具,而在于你对系统的理解和对瓶颈的洞察。
选一个你用得最顺手的工具,然后把它用透。比换来换去强得多。