压测工具选型:JMeter、LoadRunner、wrk、ab、Locust 的优缺点对比

做性能压测这么多年,我经常被问到同一个问题:「到底该用哪个工具?」

说实话,没有银弹。每个工具都有自己的脾气。你想想看,用菜刀切西瓜和用水果刀削苹果,能是一回事吗?

今天我就把这几个主流工具掰开揉碎了讲。我踩过的坑,你就不用再踩了。

核心观点:选工具不是选最火的,而是选最合适的。你的业务场景、团队技术栈、预算,这三个因素决定了最终答案。

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(最简单,预装) 复杂场景(全链路) JMeter(生态丰富) LoadRunner(企业级) Python 技术栈? Locust(灵活,可编程) 注:实际选型需结合团队技术栈、预算、协议支持等因素综合评估

最终建议:怎么选?

说了这么多,我总结一下我的个人经验:

  1. 如果你是开发,想快速验证接口性能 → 用 wrk 或 ab。5 分钟上手,10 秒出结果。
  2. 如果你是测试,要做全链路压测 → 用 JMeter。生态好,社区强,遇到问题容易找到答案。
  3. 如果你在银行、保险等传统行业 → 考虑 LoadRunner。虽然贵,但那些冷门协议只有它能搞定。
  4. 如果你团队全是 Python 开发者 → 用 Locust。写脚本就像写业务代码一样自然。

最后说一句:工具只是手段,不是目的。我见过有人用 ab 跑出了 10 万 QPS,也见过有人用 JMeter 连 1000 并发都跑不稳。关键不在于工具,而在于你对系统的理解和对瓶颈的洞察。

选一个你用得最顺手的工具,然后把它用透。比换来换去强得多。

可可精品资料库