吞吐压测与显存优化全流程：压测工具选型
做压测这么多年，我经常被问到同一个问题：「到底该用哪个工具？」
说实话，没有银弹。每个工具都有自己的脾气。我见过有人用 JMeter 压一个简单的 API，结果配置环境就花了两天。也见过有人用 wrk 压复杂业务流，最后发现根本模拟不了真实场景。
今天咱们就把 wrk、ab、Locust、JMeter 这四个主流工具掰开揉碎，聊聊它们各自的优缺点，以及我个人的选型经验。
一、先看一张对比图，心里有个谱
我习惯把工具分成两类：轻量级 CLI 工具和重量级 GUI 平台。wrk 和 ab 属于前者，Locust 和 JMeter 属于后者。先看这张图，你就能明白它们各自的定位。
二、逐个拆解：每个工具到底能干什么
1. wrk：高性能压测的「瑞士军刀」
wrk 是我个人最常用的工具。为什么？因为它快、轻、准。它利用操作系统的事件驱动机制，用很少的线程就能打出很高的并发。
核心优势：
- 单机就能压出几十万 QPS
- 支持 Lua 脚本，可以自定义请求
- 结果输出简洁，适合自动化集成
我记得有一次，线上服务突然出现偶发超时。我用 wrk 配合 Lua 脚本，模拟了带 token 的登录态请求，很快就复现了问题。如果当时用 JMeter，光配置 token 关联就得折腾半天。
# 一个典型的 wrk 压测命令
wrk -t12 -c400 -d30s --latency http://localhost:8080/api/v1/users
# 带 Lua 脚本的自定义压测
wrk -t4 -c200 -d60s -s custom.lua http://localhost:8080/api/v1/order我的经验：wrk 最适合压测单一接口或简单链路。如果你需要压测一个完整的业务流程（比如下单→支付→退款），wrk 的 Lua 脚本写起来会比较痛苦。
2. ab (Apache Bench)：最简单的压测工具
ab 是 Apache 自带的压测工具。说实话，它功能很弱，但胜在简单。你不需要安装任何东西，只要装了 Apache 就能用。
# ab 的基本用法
ab -n 10000 -c 100 http://localhost:8080/api/health但我要提醒你：ab 是单线程的。这意味着它压不了太高的并发。我曾经试过用 ab 压一个 QPS 过万的服务，结果 ab 自己先成了瓶颈——CPU 跑满了，但请求发不出去。
避坑指南：我曾经在线上环境用 ab 做压测，结果压测机本身负载过高，导致压测结果失真。后来我改用 wrk，同样配置下，压测机 CPU 占用率从 90% 降到了 20%。
3. Locust：Python 工程师的「心头好」
Locust 是一个基于 Python 的压测工具。它的设计理念很特别：用代码定义用户行为。你写一个 Python 类，描述用户会做什么操作，然后 Locust 会模拟成千上万个这样的用户。
# Locust 的典型用法
from locust import HttpUser, task, between
class WebsiteUser(HttpUser):
wait_time = between(1, 5)
@task(3)
def view_items(self):
self.client.get("/items")
@task(1)
def add_to_cart(self):
self.client.post("/cart", json={"item_id": 123})我个人觉得 Locust 最大的优点是分布式压测。你可以用一台机器做 master，多台机器做 worker，轻松压出百万级并发。而且它自带 Web UI，实时查看 TPS、响应时间、错误率，非常直观。
适用场景：
- 需要模拟复杂用户行为的场景
- 需要分布式压测的场景
- 团队以 Python 为主的技术栈
4. JMeter：企业级的「压测全家桶」
JMeter 是压测界的「老大哥」。功能最全，插件最多，学习曲线也最陡。它支持 GUI 拖拽式配置，也支持命令行执行。
说实话，我平时很少用 JMeter。但有一次，客户要求压测一个包含登录→查询→下单→支付→回调的全链路场景，而且需要生成详细的 HTML 报告。这时候 JMeter 就派上用场了——它的逻辑控制器和断言功能，让复杂场景的配置变得相对简单。
我的建议：如果你在大型企业，或者需要输出标准化的压测报告给客户/领导看，JMeter 是首选。但如果你只是自己排查性能问题，用 wrk 或 Locust 效率更高。
三、如何根据场景选择工具？
我总结了一个简单的选型原则：看你的压测目标是什么。
| 场景 | 推荐工具 | 原因 |
|---|---|---|
| 快速验证接口性能 | wrk / ab | 命令一行搞定，结果秒出 |
| 压测单接口高并发 | wrk | 性能最好，资源占用最低 |
| 模拟复杂用户行为 | Locust | Python 脚本灵活，分布式方便 |
| 全链路压测 + 报告输出 | JMeter | 插件丰富，报告专业 |
| CI/CD 集成压测 | wrk / Locust | 命令行友好，结果可解析 |
| 临时排查线上问题 | wrk | 安装简单，启动快，不污染环境 |
重要提醒：不管你选哪个工具，压测机的性能一定要足够。我见过太多人用一台 2 核 4G 的机器去压测，结果压测机自己先崩了。一般来说，压测机的 CPU 和内存至少要是被压服务的 2 倍以上。
四、我的个人选型「三板斧」
说了这么多，我分享一下自己实际工作中的选型流程：
- 第一板斧：快速验证用 wrk
接到一个性能问题，我第一反应就是打开终端，敲一行 wrk 命令。10 秒内就能看到 QPS、延迟、错误率。如果问题明显，这一步就能定位。
- 第二板斧：复杂场景用 Locust
如果 wrk 搞不定（比如需要登录态、需要多步骤操作），我会写一个 Locust 脚本。Python 写起来快，而且可以复用现有的测试代码。
- 第三板斧：正式报告用 JMeter
如果压测结果需要给老板看，或者需要作为项目交付物，我会用 JMeter 重新跑一遍。它的 HTML 报告确实专业，各种图表一目了然。
一个小技巧：我习惯把 wrk 和 Locust 的压测脚本放在项目的 benchmark/ 目录下，和代码一起版本管理。这样每次代码变更后，跑一下压测脚本，就能快速发现性能回退。
好了，关于压测工具选型，今天就聊到这里。记住一句话：没有最好的工具，只有最适合场景的工具。下次遇到压测需求，先想清楚你的目标是什么，再选工具，事半功倍。
想要更多资料，联系可可