压测工具选型：wrk、ab、JMeter、Locust、Go-stress-testing 对比
做压测这么多年，我经常被问到同一个问题：「到底该用哪个工具？」
说实话，没有银弹。每个工具都有自己的脾气。我见过有人用 ab 测长连接，结果数据惨不忍睹；也见过团队用 JMeter 压一个简单接口，光配置就花了两天。
今天我把主流工具拉出来遛遛。咱们不吹不黑，就聊聊我实际用下来的感受。
先看一张图，心里有个谱
wrk：我的压箱底工具
wrk 是我个人最常用的工具。为什么？因为它够快，够轻。
它基于 C 语言 + libuv 事件驱动，单机就能压出很高的并发。我习惯用它来做接口的快速摸底。
核心优势：
- 单机并发能力极强，轻松上万连接
- 支持 Lua 脚本，可以自定义请求逻辑
- 资源占用极低，压测本身不成为瓶颈
举个例子，我压一个简单的 GET 接口：
wrk -t12 -c400 -d30s http://target.com/api/health这条命令的意思是：12 个线程，400 个连接，持续 30 秒。结果里会直接告诉你 QPS、延迟分布。
我的小技巧： 用 wrk 做基准测试时，先跑一轮短时间的（比如 10 秒），看看大概水位。然后再加长时间做稳定测试。别一上来就压 10 分钟，万一接口有问题，你连调试的机会都没有。
注意： wrk 不支持 Windows 原生运行。如果你在 Windows 上开发，要么用 WSL，要么换工具。我曾经因为这个折腾了半天，最后老老实实装了 Ubuntu 虚拟机。
ab：老牌工具，但别太依赖它
ab（Apache Bench）是 Apache 自带的压测工具。说实话，我现在用得少了。但它有个好处：几乎每台 Linux 服务器都自带。
我记得有一次线上出问题，我手边没有任何压测工具。apt-get install 又慢得要命。最后直接用 ab 顶上去，好歹把问题复现了。
ab -n 10000 -c 100 http://target.com/api/health这条命令：总共 10000 个请求，并发 100。
ab 的硬伤：
- 只支持 HTTP/1.0，不支持连接复用
- 无法模拟复杂的业务逻辑
- 高并发下自身性能会下降
说白了，ab 适合做「有没有问题」的快速验证。但你要做精细化的性能分析，它不够格。
JMeter：功能最全，但也是最重的
JMeter 是 Java 生态里的老大哥。我见过很多大厂团队都在用。它的插件生态非常丰富，几乎什么协议都能测：HTTP、JDBC、JMS、FTP……
但我要说句实话：JMeter 太重了。启动慢，吃内存，配置复杂。我见过有人为了压一个简单的 REST 接口，在 JMeter 里拖了十几个组件。
什么时候用 JMeter？
- 需要复杂的测试场景编排（比如登录→下单→支付）
- 需要生成详细的 HTML 报告
- 团队里有人习惯用 GUI 工具
避坑指南： 我曾经用 JMeter 压一个高并发场景，结果 JMeter 自己先 OOM 了。后来发现是监听器配置太多，每个请求都要写日志。记住：压测时关掉不必要的监听器，用命令行模式运行。
Locust：Python 玩家的首选
Locust 是我最近两年用得越来越多的工具。原因很简单：用 Python 写压测脚本。
你想想看，如果你团队里都是 Python 工程师，让他们去学 JMeter 的 XML 配置，或者 wrk 的 Lua 脚本，是不是有点反人性？
from locust import HttpUser, task, between
class WebsiteUser(HttpUser):
wait_time = between(1, 5)
@task
def index(self):
self.client.get("/")这段代码定义了一个用户行为：每隔 1-5 秒访问一次首页。简单、直观、可扩展。
Locust 的亮点：
- 基于协程，单机并发能力不错
- 支持分布式，可以横向扩展
- Web UI 实时查看结果
我的经验： Locust 的 Web UI 在压测过程中会消耗一些资源。如果你追求极致性能，建议用 --headless 模式运行，只收集数据。
Go-stress-testing：后起之秀
这个工具是 Go 语言写的。说实话，我一开始没太在意它。直到有一次我需要压一个 WebSocket 服务，wrk 不支持，JMeter 配置太麻烦，Locust 的 WebSocket 支持又不够成熟。
最后试了 Go-stress-testing，真香。
go-stress-testing -c 100 -n 10000 -u http://target.com/api/health它的优势：
- 单机并发能力极强（Go 的 goroutine 优势）
- 支持 HTTP、WebSocket、TCP 等多种协议
- 编译成二进制，部署简单
不过它也有缺点：社区相对较小，文档不够完善。如果你遇到奇怪的问题，可能得自己读源码。
横向对比：一张表说清楚
| 特性 | wrk | ab | JMeter | Locust | Go-stress-testing |
|---|---|---|---|---|---|
| 语言 | C | C | Java | Python | Go |
| 单机并发 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 脚本灵活性 | ⭐⭐⭐ | ⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 学习成本 | 低 | 极低 | 高 | 中 | 低 |
| 协议支持 | HTTP | HTTP | 多协议 | HTTP + 扩展 | HTTP/WebSocket/TCP |
| 分布式支持 | 否 | 否 | 是 | 是 | 有限 |
| 报告生成 | 命令行 | 命令行 | HTML/图表 | Web UI | 命令行 |
我个人的选型建议
说了这么多，到底怎么选？我总结几条经验：
- 快速摸底、基准测试 → 用 wrk。轻量、高效、不废话。
- 简单验证、临时救急 → 用 ab。服务器自带，拿来就用。
- 复杂业务场景、团队协作 → 用 JMeter。虽然重，但功能全。
- Python 团队、快速迭代 → 用 Locust。脚本即代码，维护成本低。
- 高并发、多协议、部署简单 → 用 Go-stress-testing。后起之秀，值得一试。
最后说一句： 工具只是手段，不是目的。我见过有人用 wrk 压出了漂亮的 QPS 数据，但上线后系统还是崩了。为什么？因为压测场景和真实流量不一样。所以，理解你的系统，比选对工具更重要。
想要更多资料，联系可可