吞吐测试基础：吞吐量、TPS/QPS 与响应时间

吞吐测试，说白了就是看系统到底能扛多少活。我刚开始做性能测试那会儿，总觉得这玩意儿就是拼命加压，看系统什么时候挂掉。后来踩了不少坑才明白——吞吐量不是压出来的，是设计出来的。

这一章我们先把地基打牢。吞吐量、TPS、QPS、响应时间，这几个概念搞不清楚，后面的优化全是瞎忙活。

吞吐量（Throughput）的定义很简单：单位时间内系统成功处理的请求数量。单位可以是秒、分钟、小时，看场景。

举个例子。你有个支付接口，1 分钟内处理了 3000 笔订单。那吞吐量就是 3000 笔/分钟，或者换算成 50 笔/秒。

核心公式：

吞吐量 = 成功处理的总请求数 / 总耗时

注意是「成功处理」。失败的请求不算。我见过有人把 4xx、5xx 也算进去，那叫自欺欺人。

吞吐量不是越高越好。你得看业务场景。一个银行核心系统的吞吐量可能只有几百 TPS，但每笔都得保证强一致性。一个短视频推荐接口，吞吐量可能上万 TPS，丢几条数据也无所谓。

这两个概念，面试常问，实际工作中也容易搞混。我简单说清楚。

指标	全称	含义	典型场景
TPS	Transactions Per Second	每秒完成的事务数	下单、转账、支付
QPS	Queries Per Second	每秒完成的查询数	搜索、列表、详情页

TPS 强调的是「事务」。一个事务可能包含多个操作。比如你在电商下单：扣库存、生成订单、减优惠券、更新积分——这四个操作合起来才算一个完整事务。

QPS 强调的是「查询」。一次请求就是一次查询，没有复杂的业务逻辑链。

我的习惯： 做接口测试时，如果接口只做读操作，我直接用 QPS。如果涉及写操作或跨服务调用，我倾向于用 TPS。这样跟开发沟通时不容易产生歧义。

举个例子。你测一个搜索接口，每秒能处理 5000 次请求。这就是 5000 QPS。你测一个下单接口，每秒能完成 200 笔订单。这就是 200 TPS。

这是性能测试里最核心的关系，没有之一。

很多人以为响应时间越短，吞吐量就越高。其实不完全对。我画个图你就明白了。

看到没？在拐点之前，系统处于健康状态。响应时间波动不大，吞吐量随着并发增加而线性增长。一旦过了拐点，响应时间开始飙升，吞吐量反而下降——系统已经过载了。

我曾经踩过的坑： 有一次压测一个订单系统，发现响应时间从 50ms 涨到 200ms，但吞吐量还在涨。我以为是好事，继续加压。结果 300ms 的时候，数据库连接池爆了，系统直接雪崩。后来我才明白——响应时间翻倍的时候，就该停下来分析了，而不是继续加压。

这里有个经验公式：当响应时间超过基线的 2 倍时，大概率已经接近系统瓶颈。别等到响应时间涨了 10 倍才收手。

做吞吐测试，不能上来就乱压。你得有个模型。我常用的模型分四个阶段。

我的建议： 别跳过基准测试。很多人觉得单用户没意义，直接上负载。结果发现响应时间异常，还得回头排查。基准测试花不了 5 分钟，但能帮你省下半天排查时间。

做吞吐测试这么多年，我见过太多人犯同样的错误。列几个典型的。

误区一：吞吐量越高越好。不对。你得看业务容忍度。支付接口 99% 的请求必须在 200ms 内完成，那吞吐量再高，响应时间超了也是白搭。
误区二：TPS 和 QPS 混用。我见过有人把 QPS 当 TPS 报给老板，结果线上出了问题。记住：写操作用 TPS，读操作用 QPS。
误区三：只看平均值。平均值会骗人。100 个请求，99 个 10ms，1 个 10s，平均值才 109ms。但那个 10s 的请求已经超时了。一定要看 TP99、TP999。
误区四：忽略资源消耗。吞吐量上去了，CPU 100%、内存飙高、磁盘 IO 打满——这种吞吐量不可持续。我习惯在压测时同时监控 CPU、内存、网络、磁盘、连接池。

我曾经犯过的错： 有一次压测，吞吐量从 1000 TPS 涨到 3000 TPS，我高兴坏了。结果一看监控，CPU 已经 95% 了，GC 频率从每秒 1 次变成了每秒 20 次。这种吞吐量是虚的，稍微加点流量就崩。后来我给自己定了个规矩：吞吐量翻倍，CPU 涨幅不能超过 30%。

吞吐测试不是简单的加压看数字。你得理解吞吐量的本质，分清 TPS 和 QPS，掌握响应时间与吞吐量的关系，用科学的模型去测试。

记住几个关键点：