吞吐压测基础：吞吐量、QPS/TPS与核心指标

做性能优化这些年，我见过太多团队一上来就堆机器、调参数，结果压测一跑，系统直接崩了。说白了，很多人连最基本的吞吐量概念都没搞清楚。今天咱们就把这块地基打牢。

吞吐量，英文叫 Throughput。你可以把它想象成一条高速公路——单位时间内能通过多少辆车。在系统里，就是单位时间内能处理多少请求。

我习惯用这个公式来理解：

吞吐量 = 成功处理的请求数 / 时间单位

举个例子。你的接口每秒能处理 1000 个请求，那吞吐量就是 1000 req/s。但注意，这里有个坑——必须是成功处理的请求。返回 500 错误的，不算。

核心要点：吞吐量衡量的是系统的处理能力，不是并发数，也不是响应时间。它是三者综合的结果。

这两个概念，面试常考，实际也常搞混。我简单说清楚。

指标	全称	含义	典型场景
QPS	Queries Per Second	每秒查询数	读接口、搜索服务
TPS	Transactions Per Second	每秒事务数	下单、支付、转账

QPS 偏重查询，一个请求可能只查一次数据库。TPS 偏重事务，一个请求可能涉及多次读写、多个服务调用。比如你点个「提交订单」，后端可能要扣库存、减余额、写订单表——这就算一个 TPS，但内部可能产生了 5 个 QPS。

我的经验：压测时我一般先看 QPS，因为它更直观。但如果系统涉及写操作，TPS 才是真正的瓶颈指标。曾经有个项目，QPS 看着很高，一查 TPS 低得可怜——原来大部分请求都在读缓存，真正的写操作全堵在数据库了。

这三个指标，缺一不可。你想想看，光看吞吐量够吗？不够。我给你拆开讲。

延迟就是响应时间。从发出请求到收到响应，花了多久。我一般关注这几个分位值：

为什么看分位值而不是平均值？因为平均值太容易被「平均」了。举个例子：99 个请求 10ms，1 个请求 10s，平均值才 109ms，看着还行。但 P99 是 10s——用户早跑了。

避坑指南：我曾经压测一个支付系统，只看平均延迟 50ms，觉得稳了。上线后用户投诉卡顿，一查 P99 延迟 2.3 秒。原来有个慢 SQL 偶尔触发，平均延迟被「稀释」了。从那以后，我压测报告里必须带 P99。

并发是系统同时处理的请求数。注意，它不是 QPS。并发和 QPS 的关系是：

并发数 = QPS × 平均响应时间（秒）

这个公式叫 Little's Law，做性能优化的人应该刻在脑子里。举个例子：QPS 是 1000，平均响应时间 200ms，那并发数就是 1000 × 0.2 = 200。也就是说，系统同时有 200 个请求在处理。

压测时，我会逐步增加并发数，观察系统的变化。一开始延迟很低，QPS 线性增长。到某个点，延迟突然飙升，QPS 不再增长甚至下降——这就是系统的拐点。

关键认知：并发不是越高越好。过高的并发会导致资源争抢、上下文切换开销暴增，反而降低吞吐量。找到那个「甜蜜点」才是本事。

这个最简单，也最容易被忽略。成功率 = 成功请求数 / 总请求数。一般要求 99.9% 以上。

压测时，我习惯把成功率放在监控大屏最显眼的位置。为什么？因为很多系统在压力下会悄悄失败——超时、限流、报错。如果只看 QPS 和延迟，可能觉得还行，但成功率已经掉到 95% 了。每 20 个请求就失败 1 个，这能上线吗？

我的习惯：压测脚本里必须加断言。比如 HTTP 状态码必须是 200，响应体必须包含 "success"。别只看网络层面通不通，业务层面也得对。

下面这张 SVG 图，是我自己总结的吞吐压测知识体系。你看一遍，基本就全串起来了。

说了这么多理论，最后给点实在的。我每次压测，报告里必须包含这 5 个数字：

一句话总结：吞吐压测不是跑个数字就完事了。你得理解延迟、并发、成功率这三个指标怎么互相制约。找到那个平衡点，才是真本事。

嗯，这一章就到这里。概念打牢了，后面咱们才能聊怎么压、怎么优化。

想要更多资料，联系可可