吞吐测试工具概览：主流工具与选型对比
做吞吐测试这么多年，我接触过的工具少说也有七八种。说实话，没有哪个工具是万能的。每个工具都有自己的脾气，选对了事半功倍，选错了……嗯，我见过有人在 JMeter 里硬写几千行脚本测 gRPC，折腾了两周，最后换 wrk 半天搞定。
这一章，我把市面上最主流的吞吐测试工具捋一遍。你会看到它们各自的强项、短板，以及我踩过的坑。最后给出一张对比矩阵，帮你快速决策。
wrk：轻量级 HTTP 压测利器
wrk 是我个人最常用的工具之一。它用 C 语言写的，基于 epoll/kqueue 事件驱动，单机就能压出很高的并发。说白了，它就是为「纯 HTTP 吞吐」而生的。
核心特点：
- 单线程就能跑满千兆网卡
- 支持 Lua 脚本定制请求逻辑
- 输出简洁：延迟分布、吞吐量、错误率
我记得有一次线上排查 Nginx 性能瓶颈，用 wrk 跑了 30 秒就定位到是 keepalive 配置问题。要是换别的工具，光启动 GUI 就得等半天。
# 基本用法：10 个连接，持续 30 秒
wrk -t4 -c10 -d30s http://target.com/api
# 带 Lua 脚本：模拟登录态
wrk -t2 -c20 -d60s -s login.lua http://target.com/api我的建议：wrk 适合快速验证、对比测试、单机极限压测。但别用它测复杂业务流程——Lua 脚本能力有限，调试起来也麻烦。
ab（Apache Bench）：老牌工具，简单粗暴
ab 是 Apache 自带的压测工具，几乎每个 Linux 服务器上都预装了。它的优点就一个字：快。一条命令就能跑起来，适合临时验证。
但说实话，ab 的局限性也很明显。它只支持 HTTP/1.0 和 HTTP/1.1，不支持 HTTPS 的完整握手复用。我曾经用它压一个 HTTPS 接口，结果发现大部分时间都花在 SSL 握手上了，根本不是真实场景。
# 100 个请求，10 个并发
ab -n 100 -c 10 http://target.com/
# 带 Keep-Alive
ab -k -n 1000 -c 50 http://target.com/避坑指南：ab 的并发模型是 fork 子进程，高并发下资源消耗很大。我曾经在 4 核机器上用 ab 压 500 并发，结果 ab 自己先挂了。别用它做大规模压测。
JMeter：企业级全能选手
JMeter 是 Java 生态里的老大哥。它支持 HTTP、JDBC、gRPC、JMS……几乎你能想到的协议它都有插件。而且有 GUI，脚本录制、参数化、断言都很方便。
不过，JMeter 的吞吐能力是个硬伤。Java 的线程模型在高并发下会吃很多内存。我记得有个项目，用 JMeter 压 2000 并发，结果压测机 32G 内存直接打满，GC 停顿导致结果失真。
适用场景：
- 复杂业务流程（登录→下单→支付）
- 多协议混合压测
- 分布式压测（需要多台机器）
- 结果报表要求高（JMeter 自带图表）
# 命令行模式（非 GUI）
jmeter -n -t test_plan.jmx -l results.jtl -e -o report_dir我的经验：JMeter 的 GUI 只用来调试脚本。真正跑压测一定要用命令行模式，不然 GUI 本身就会吃掉大量资源。
Locust：Python 爱好者的选择
Locust 用 Python 写脚本，代码即配置。你想想看，如果你团队里都是 Python 工程师，用 Locust 几乎零学习成本。它的协程模型（基于 gevent）也比 JMeter 的线程模型轻量不少。
但 Locust 的弱点也很明显：单机吞吐上限不如 wrk，而且对 HTTP/2 的支持一直不完善。我曾经用它压一个 HTTP/2 的 gRPC 服务，折腾了半天才发现 Locust 默认走 HTTP/1.1，结果数据完全不对。
# locustfile.py
from locust import HttpUser, task, between
class MyUser(HttpUser):
wait_time = between(1, 3)
@task
def get_index(self):
self.client.get("/")注意：Locust 的 Web UI 在压测过程中会消耗额外资源。高并发场景下建议用 --headless 模式。
Vegeta：Go 生态的精准打击
Vegeta 是我最近两年用得越来越多的工具。它用 Go 写的，二进制文件就一个，扔到服务器上就能跑。它的设计哲学很纯粹：恒定速率压测，而不是最大并发。
为什么说这个重要？因为很多工具（比如 wrk）是「尽力而为」地发请求，结果你看到的吞吐量其实是工具能发出的最大速率，而不是服务端能承受的。Vegeta 让你指定每秒发多少请求，这样你能精确控制压力，观察服务在不同负载下的表现。
# 每秒发 100 个请求，持续 30 秒
echo "GET http://target.com/api" | vegeta attack -rate=100 -duration=30s | vegeta report
# 生成延迟分布图
echo "GET http://target.com/api" | vegeta attack -rate=100 -duration=30s | vegeta plot > plot.html我的推荐：如果你需要精确控制压力、做容量规划，Vegeta 是最佳选择。它的报告格式也很友好，可以直接生成延迟分布图。
工具选型对比矩阵
下面这张表是我根据多年实战经验整理的。你选工具的时候，直接对着这张表看就行。
| 维度 | wrk | ab | JMeter | Locust | Vegeta |
|---|---|---|---|---|---|
| 语言 | C | C | Java | Python | Go |
| 单机吞吐 | 极高 | 高 | 中 | 中高 | 高 |
| 协议支持 | HTTP/1.x | HTTP/1.0/1.1 | 多协议 | HTTP/1.x | HTTP/1.x |
| 脚本灵活性 | 中（Lua） | 低 | 高（GUI+代码） | 高（Python） | 低（命令行） |
| 学习成本 | 低 | 极低 | 中高 | 低 | 低 |
| 分布式支持 | 无 | 无 | 原生支持 | 原生支持 | 需自行编排 |
| 报告能力 | 弱 | 弱 | 强 | 中 | 中（可生成图） |
| 最佳场景 | 快速压测、极限吞吐 | 临时验证 | 复杂业务、多协议 | Python 团队、协程场景 | 恒定速率、容量规划 |
知识体系总览
下面这张图帮你理清这五个工具的核心定位和关系。我把它画成了「能力-场景」二维矩阵，方便你快速对号入座。
从这张图你能看出来：wrk 和 Vegeta 在单机吞吐上最强，适合纯 HTTP 压测；JMeter 和 Locust 虽然吞吐弱一些，但能处理复杂业务逻辑；ab 嘛……说实话，除了临时用用，我不太推荐在生产环境用它。
选型口诀：快速验证用 wrk，恒定速率用 Vegeta，复杂业务用 JMeter，Python 团队用 Locust，ab 只用来救急。