1. 吞吐压测基础

各位同学好，我是你们的老朋友。今天咱们聊聊吞吐压测最基础的东西——说白了，就是搞清楚你的系统到底能扛多少活。

我记得刚入行那会儿，有个前辈跟我说过一句话，我一直记到现在：「没有数据的优化，都是耍流氓」。吞吐压测，就是给你提供这些数据的。

什么是吞吐量？

先问个问题：你开了一家奶茶店，一天能卖多少杯？这个「一天能卖多少杯」，就是吞吐量。

放到系统里，吞吐量指的是单位时间内系统能处理的请求数量。常见的单位有：

• 每秒请求数（RPS）
• 每秒事务数（TPS）
• 每秒查询数（QPS）

我习惯把吞吐量理解成「系统的排水能力」。你想想看，一个水池，进水管一直在放水，排水管能排多快，这就是吞吐量。排得慢了，池子就会溢出来——对应到系统里就是请求堆积、超时、甚至崩溃。

QPS 和 TPS，到底有什么区别？

这两个概念经常被混用，但严格来说是有区别的。

指标	全称	含义	典型场景
QPS	Queries Per Second	每秒查询数	读多写少的系统，比如搜索引擎、内容展示
TPS	Transactions Per Second	每秒事务数	涉及写操作的系统，比如下单、支付、转账

举个例子：你在淘宝搜一件商品，这算一次 QPS。但如果你下单购买，从点击「立即购买」到支付成功，这整个流程才算一次 TPS。

我在项目中遇到过不少同学把这两个混为一谈，结果压测报告写得乱七八糟。嗯，这里要注意：如果你的系统既有读又有写，建议两个指标都看。

压测的核心指标

光看吞吐量是不够的。我见过太多人只盯着 QPS 数字，结果上线后用户骂声一片。为什么？因为忽略了其他关键指标。

我个人认为，压测至少要关注以下四个维度：

1. 吞吐量（Throughput）—— 系统能处理多少
2. 延迟（Latency）—— 每个请求要等多久
3. 错误率（Error Rate）—— 失败的请求占比
4. 资源利用率（Resource Utilization）—— CPU、内存、IO 等

这四个指标就像汽车的四个轮子，缺一个都跑不稳。

延迟：别被平均值骗了

说到延迟，我踩过一个坑。曾经有个项目，压测报告显示平均延迟只有 50ms，看起来挺漂亮。结果上线后，用户反馈说「卡得要死」。

后来一查才发现，平均延迟掩盖了真相。实际上有 5% 的请求延迟超过了 2 秒，这些「长尾请求」才是用户感知到的卡顿。

所以我现在看延迟，必看这几个分位值：

• P50（中位数）：一半请求比这个快，一半比这个慢
• P90：90% 的请求比这个快
• P99：99% 的请求比这个快
• P999：99.9% 的请求比这个快

错误率：容忍度是多少？

错误率这个指标，不同场景容忍度不一样。

• 对于非关键路径（比如日志上报），错误率 1% 以内可以接受
• 对于核心路径（比如支付、登录），错误率必须接近 0%
• 对于实时性要求高的场景（比如直播推流），错误率超过 0.1% 就要报警

你想想看，如果你的支付接口在压测时出现了 0.5% 的错误率，换算成真实用户量，那就是每 200 个用户就有 1 个支付失败。这个损失，业务方肯定接受不了。

资源利用率：别把机器跑冒烟了

压测的时候，很多人喜欢把 CPU 干到 100%，觉得这样才「物尽其用」。但说实话，这是很危险的做法。

我建议：CPU 利用率控制在 70%-80% 是比较健康的。留出一些余量给突发流量和系统开销。内存也是同理，别让 GC 频繁触发。

压测的目标：你到底想验证什么？

做压测之前，先问自己三个问题：

1. 系统能扛多少并发？ —— 找到容量上限
2. 瓶颈在哪里？ —— 是 CPU、内存、IO 还是网络？
3. 在目标负载下，延迟和错误率是否达标？ —— 验证 SLA

说白了，压测不是为了跑个好看的数字出来，而是为了发现系统的薄弱环节。

我记得有一次给一个电商平台做压测，刚开始 QPS 只能到 2000，再往上就各种超时。后来一步步排查，发现是数据库连接池配得太小了。把连接数从 20 调到 100，QPS 直接飙到了 8000。你看，这就是压测的价值——找到那个「卡脖子」的地方。

知识体系一览

下面这张图，是我自己梳理的吞吐压测知识体系。你可以把它当成一个地图，后面几章我们会逐个深入。

写在最后

这一章我们聊了吞吐压测的基础概念。说实话，这些概念看起来简单，但真正用好它们，需要大量的实战经验。

我见过太多人拿着压测工具跑了一堆数据，却不知道怎么看、怎么分析。所以我的建议是：先理解指标的含义，再动手去压。否则你跑出来的数字，只是一堆没有灵魂的阿拉伯数字而已。