📚 课程目录第2章压测工具选型

2. 压测工具选型

说到压测工具选型，我见过不少团队在这个问题上栽跟头。有人拿着JMeter去压高并发接口，结果压测机自己先挂了；有人用wrk测了一整天，最后发现数据根本没法看。说白了，选错工具比不压测更可怕。

今天我就把这几个主流工具掰开揉碎了讲。你想想看，一个工具好不好用，关键看三点：能不能压出真实瓶颈、资源开销大不大、结果好不好分析。咱们就从这几个维度入手。

一、工具全景对比

先给个总览，我习惯用一张表把核心差异说清楚。这样你选型时心里就有谱了。

工具	语言	并发模型	协议支持	资源开销	适用场景
wrk	C/Lua	多线程+epoll	HTTP/HTTPS	极低	高并发、短连接
ab	C	单线程+多进程	HTTP/HTTPS	低	快速验证、简单场景
JMeter	Java	线程池	HTTP/HTTPS/数据库/自定义	高	复杂业务、分布式压测
Locust	Python	协程(gevent)	HTTP/自定义	中等	灵活脚本、动态场景
Vegeta	Go	goroutine	HTTP/HTTPS	低	持续压测、结果可视化

嗯，这里要注意。表格里写的"资源开销"，指的是压测工具本身对CPU和内存的消耗。我见过有人用JMeter压10000并发，结果JMeter自己先吃了8G内存，这还测个啥？

二、逐个工具深度分析

1. wrk：我的压测首选

我个人习惯用wrk做日常压测。为什么？因为它够轻、够快、够直接。底层用的是epoll多路复用，单机就能压出几十万并发。

举个例子，我去年优化一个API网关，用wrk压了30秒就发现了连接池瓶颈：

wrk -t12 -c400 -d30s http://target-api:8080/hello

这条命令的意思是：12个线程、400个并发连接、持续30秒。结果里会直接告诉你吞吐量、延迟分布、错误率。干净利落。

我的小技巧： wrk支持Lua脚本，可以自定义请求构造和响应处理。比如你想模拟登录态，写个Lua脚本生成带token的请求就行。我经常用这个功能做带状态的压测。

2. ab：简单场景的快速验证

ab是Apache自带的压测工具，说实话功能比较简陋。但它有个好处——几乎每台Linux机器上都自带。我有时候临时要验证一下接口通不通，直接敲一行ab就完事了。

ab -n 10000 -c 100 http://target-api:8080/hello

不过要提醒你，ab的并发模型是单线程多进程，高并发下性能会急剧下降。我曾经用ab压5000并发，结果压测机CPU直接飙到100%，数据完全不可信。所以它只适合做快速验证，别拿它做正式压测。

避坑指南： 我曾经在压测长连接服务时用了ab，结果发现所有连接都卡住了。后来一查，ab默认不支持Keep-Alive的复用，每个请求都新建TCP连接。你想想看，这在高并发场景下就是灾难。

3. JMeter：复杂场景的瑞士军刀

JMeter功能确实强大。支持HTTP、数据库、JMS、FTP等各种协议，还能做分布式压测。我团队里做全链路压测时，用的就是JMeter。

但它的缺点也很明显——重。启动慢、内存吃得多、脚本配置繁琐。我见过有人为了压一个简单的GET接口，在JMeter里拖了十几个组件，最后压测机自己先OOM了。

我的建议是：如果你的压测场景涉及多个协议、需要复杂的参数化关联、或者要做分布式压测，选JMeter没错。但如果只是压个REST API，别用它，杀鸡焉用牛刀。

4. Locust：Python党的最爱

Locust用Python写压测脚本，灵活性极高。你可以用Python代码定义用户行为、动态调整并发数、甚至实时修改压测参数。我有个朋友用它模拟了1000个用户的不同操作路径，代码写起来比JMeter的XML配置爽多了。

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 5)
    
    @task
    def hello(self):
        self.client.get("/hello")
    
    @task(3)
    def login(self):
        self.client.post("/login", {"username": "test", "password": "123"})

不过要注意，Locust底层用的是gevent协程，虽然并发能力不错，但遇到CPU密集型操作时会阻塞事件循环。我踩过这个坑——在压测脚本里加了个复杂的加密计算，结果吞吐量直接掉了一半。

5. Vegeta：持续压测与结果分析

Vegeta是Go写的，天生就适合做持续压测。它的输出格式非常友好，可以直接生成延迟分布图、吞吐量趋势图。我经常用它做长时间压测，比如跑个12小时看看系统有没有内存泄漏。

echo "GET http://target-api:8080/hello" | vegeta attack -rate=1000 -duration=60s | vegeta report

Vegeta的report命令会输出详细的百分位延迟数据，包括P50、P90、P99。这对分析系统性能瓶颈特别有用。我一般先看P99，如果P99比P50高出一个数量级，那说明系统存在长尾延迟问题。

三、选型决策树

说了这么多，到底怎么选？我画了个决策流程图，你照着走一遍就知道该用哪个了。

四、我的实战建议

最后说点实在的。我做了这么多年压测，总结了几条铁律：

压测机资源要够：压测机本身的CPU和内存不能成为瓶颈。我一般要求压测机资源至少是被压服务的2倍。
先小后大：别一上来就压10万并发。先压1000，看看系统反应，再逐步往上加。我见过有人直接压10万，结果把数据库打挂了，恢复了一整天。
关注P99延迟：平均延迟是骗人的。P99延迟才能反映真实用户体验。我优化系统时，永远先看P99。
多工具交叉验证：同一个场景，用两个不同的工具压一下。如果结果差异很大，那说明某个工具有问题。我遇到过wrk和JMeter压同一个接口，结果差了30%，最后发现是JMeter的线程模型导致的。

  核心总结： 选压测工具没有银弹。wrk适合高并发快速验证，ab适合临时测试，JMeter适合复杂场景，Locust适合灵活脚本，Vegeta适合持续压测。关键是根据你的场景选对工具，别让工具本身成为瓶颈。

好了，工具选型这块就聊到这儿。记住一点：工具只是手段，理解系统瓶颈才是目的。别在工具选型上纠结太久，赶紧动手压起来才是正道。