吞吐测试基础：从概念到实战

吞吐测试，说白了就是回答一个问题：系统到底能扛多少活？我刚开始做性能测试那会儿，总觉得这玩意儿就是压一压、看看数字。后来踩了不少坑才明白——吞吐量不是孤立的数据，它和响应时间、并发用户、系统资源全都绑在一起。这一章，咱们先把地基打牢。

吞吐量（Throughput）的单位取决于你测的是什么。Web 系统看每秒请求数，数据库看每秒事务数，文件传输看每秒字节数。我个人习惯把它理解为：单位时间内系统成功完成的工作量。

核心公式

吞吐量 = 完成的事务数 / 时间单位

举个例子：一个支付接口在 60 秒内处理了 12000 笔交易，那它的吞吐量就是 200 TPS。

这里有个坑——“成功完成”这四个字很关键。我在项目中遇到过测试报告显示吞吐量很高，结果一查，50% 的请求返回了 500 错误。那叫“错误吞吐”，不是真正的吞吐量。所以，统计时一定要过滤掉非 2xx/3xx 的响应。

很多新手问我：TPS 和 QPS 到底啥区别？嗯，咱们用一张表说清楚。

指标	全称	含义	典型场景
TPS	Transactions Per Second	每秒完成的事务数	数据库写入、下单、转账
QPS	Queries Per Second	每秒完成的查询数	搜索引擎、读接口、页面加载

你想想看，一个事务可能包含多个查询。比如用户下单这个事务，它要查库存、扣余额、生成订单——这算 1 个 TPS，但可能对应 5 个 QPS。我建议在测试报告中同时标注 TPS 和 QPS，不然别人看不懂你到底测了啥。

我的习惯

写测试报告时，我会在 TPS 旁边加一列“事务成功率”。如果成功率低于 99.9%，那个 TPS 数据就不具备参考价值。曾经有一次，我因为没加这列，被运维同事追着问了一下午……

这是性能测试里最经典的关系——响应时间越长，吞吐量越低。为什么？

假设一个接口平均响应时间是 100ms，那单线程每秒最多能处理 10 个请求。如果响应时间涨到 200ms，单线程每秒就只能处理 5 个了。你想想看，这不是线性关系，是反比关系。

但现实更复杂。当并发上来后，系统开始排队，响应时间会急剧增加。我画了一张图，帮你理解这个变化过程。

看到没？拐点之前，响应时间几乎不变，吞吐量稳步上升。过了拐点，响应时间开始飙升，吞吐量反而下降。这就是系统进入“过载区”的信号。

避坑指南

我曾经接手过一个项目，测试报告显示 TPS 达到 5000，看起来很漂亮。但我仔细一看，响应时间已经涨到 5 秒了。这种“高吞吐”没有任何意义——用户不会等 5 秒。记住：高吞吐必须建立在可接受的响应时间之上。

这个模型是我入行时师傅教我的。它把性能测试分成三层，每一层都有不同的目标。

这个模型告诉我们三件事：

底层测试要够多——单元测试和组件测试跑得快，能快速发现性能瓶颈。我习惯在写代码时就加上性能断言，比如“这个查询必须在 50ms 内返回”。
中间层是主战场——服务集成测试最接近真实场景，也最容易暴露问题。我记得有一次，单测全部通过，但一上集成测试，数据库连接池直接被打满。这就是金字塔中间层的价值。
顶层测试要精不要多——端到端测试成本高、执行慢，只用来验证关键业务场景。别把全链路压测当成日常工具，那是大炮打蚊子。

我的实战建议

如果你刚开始搭建性能测试体系，我建议从中间层入手。先搞定几个核心接口的压测，再往底层和顶层扩展。别一上来就搞全链路，那会把你累死，而且问题定位也难。

吞吐测试不是扔个压测工具跑一跑就完事。你得搞清楚：