吞吐压测与显存峰值优化实战：压测工具选型
说到压测工具选型，我见过不少团队在这个问题上栽跟头。有人拿着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秒。结果里会直接告诉你吞吐量、延迟分布、错误率。干净利落。
2. ab：简单场景的快速验证
ab是Apache自带的压测工具，说实话功能比较简陋。但它有个好处——几乎每台Linux机器上都自带。我有时候临时要验证一下接口通不通，直接敲一行ab就完事了。
ab -n 10000 -c 100 http://target-api:8080/hello不过要提醒你，ab的并发模型是单线程多进程，高并发下性能会急剧下降。我曾经用ab压5000并发，结果压测机CPU直接飙到100%，数据完全不可信。所以它只适合做快速验证，别拿它做正式压测。
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 reportVegeta的report命令会输出详细的百分位延迟数据，包括P50、P90、P99。这对分析系统性能瓶颈特别有用。我一般先看P99，如果P99比P50高出一个数量级，那说明系统存在长尾延迟问题。
三、选型决策树
说了这么多，到底怎么选？我画了个决策流程图，你照着走一遍就知道该用哪个了。
四、我的实战建议
最后说点实在的。我做了这么多年压测，总结了几条铁律：
- 压测机资源要够：压测机本身的CPU和内存不能成为瓶颈。我一般要求压测机资源至少是被压服务的2倍。
- 先小后大：别一上来就压10万并发。先压1000，看看系统反应，再逐步往上加。我见过有人直接压10万，结果把数据库打挂了，恢复了一整天。
- 关注P99延迟：平均延迟是骗人的。P99延迟才能反映真实用户体验。我优化系统时，永远先看P99。
- 多工具交叉验证：同一个场景，用两个不同的工具压一下。如果结果差异很大，那说明某个工具有问题。我遇到过wrk和JMeter压同一个接口，结果差了30%，最后发现是JMeter的线程模型导致的。
好了，工具选型这块就聊到这儿。记住一点：工具只是手段，理解系统瓶颈才是目的。别在工具选型上纠结太久，赶紧动手压起来才是正道。