吞吐测试基础：从定义到实战模型
吞吐测试，说白了就是看你的系统到底能扛多少活。我刚开始做性能测试那会儿，总觉得这玩意儿就是拼命压服务器，看它什么时候挂。后来踩了不少坑才明白——吞吐量不是压出来的，是设计出来的。
这一章咱们先把地基打牢。吞吐量是什么、TPS和QPS怎么区分、响应时间和吞吐量到底什么关系、性能测试模型怎么搭。这些概念搞不清楚，后面的调优全是瞎忙活。
吞吐量的定义：别被数字骗了
吞吐量（Throughput），单位时间内系统成功处理的请求数量。听起来简单对吧？但我在项目中见过太多人把「并发数」和「吞吐量」混为一谈。
核心公式：
吞吐量 = 成功处理的请求总数 / 测试持续时间单位：TPS（每秒事务数）、QPS（每秒查询数）、RPS（每秒请求数）
举个例子。你压了1000个并发用户，系统每秒只能处理200个请求。那吞吐量就是200 TPS，不是1000。并发是压力，吞吐是能力——这两个概念千万别搞反。
TPS vs QPS：什么时候用哪个？
很多新手问我：「TPS和QPS到底有什么区别？」嗯，这个问题我当年也纠结过。
| 指标 | 全称 | 适用场景 | 典型例子 |
|---|---|---|---|
| TPS | Transactions Per Second | 事务型系统（下单、支付、转账） | 一次完整的订单提交 |
| QPS | Queries Per Second | 查询型系统（搜索、列表、详情） | 一次商品搜索请求 |
| RPS | Requests Per Second | 通用场景，包含所有请求 | 任何HTTP请求 |
我个人习惯这样区分：如果一次操作涉及多个步骤（比如登录→查询→下单→支付），用TPS更合适。如果只是单纯的查询或读写，用QPS就够了。
避坑指南：我曾经在一个电商项目中，团队把QPS当TPS报给老板。结果上线后实际吞吐量只有预期的一半——因为一次下单包含了5次内部调用。所以，定义清楚你的「事务」边界，比数字本身更重要。
响应时间与吞吐量的关系：跷跷板效应
响应时间和吞吐量，就像跷跷板的两头。你压得越狠，响应时间就越长，吞吐量反而可能下降。为什么会这样？
我画个图你就明白了：
你看这张图。刚开始压测时，并发用户数增加，吞吐量跟着涨，响应时间变化不大。但到了某个点——我管它叫「拐点」——再增加并发，响应时间开始飙升，吞吐量反而往下掉。
这就是典型的系统过载现象。我在做某支付系统的压测时，亲眼看着响应时间从50ms飙到5s，吞吐量从2000 TPS跌到300 TPS。原因很简单：线程池满了，请求开始排队，排队又导致超时重试，重试又加剧了排队——恶性循环。
注意：不要追求「最大吞吐量」。最大吞吐量往往意味着响应时间已经不可接受了。合理的做法是：在响应时间满足SLA的前提下，找到吞吐量的上限。
性能测试模型：三个核心阶段
做吞吐测试，不能上来就猛压。我总结了一套模型，分三个阶段走：
- 基准测试：单用户、低压力，摸清系统的基础能力。
- 负载测试：逐步加压，找到拐点和瓶颈。
- 压力测试：持续高压，验证系统的稳定性和极限。
这三个阶段缺一不可。我见过有人跳过基准测试直接上压力，结果系统一压就崩，连是代码问题还是配置问题都分不清。
实战中的性能测试模型
下面这张图是我在实际项目中常用的测试模型：
你想想看，如果连单用户都跑不顺，压再多用户有意义吗？基准测试就是帮你确认「系统本身没问题」。负载测试是找「系统什么时候开始不行」。压力测试是看「系统不行了之后会怎样」。
一个真实的压测案例
我记得有一次帮某金融客户做吞吐测试。他们的系统号称能支撑5000 TPS，结果一压到2000 TPS就崩了。
我按三阶段模型走了一遍：
- 基准测试：单用户响应时间12ms，没问题。
- 负载测试：从100并发开始，每30秒增加100。到800并发时，响应时间突然从80ms跳到800ms。拐点出现了。
- 压力测试：在800并发下持续跑30分钟，发现内存持续增长，GC越来越频繁。
问题出在哪？数据库连接池配置了200个，但应用层的线程池只有100个。线程池满了，请求排队，排队导致数据库连接超时，超时后重试又占用了更多线程——典型的线程饥饿。
调优方案很简单：把线程池从100调到200，同时给数据库连接池留20%的余量。调整后，系统稳定跑到了4500 TPS。
我的经验：吞吐测试不是一次性的。每次代码变更、配置调整、架构升级后，都要重新跑一遍三阶段模型。我见过太多「上线前压测没问题，上线后两周就崩」的案例——因为数据量变了、用户行为变了、依赖的服务变了。
本章小结
吞吐测试的基础，说白了就三件事：搞清楚指标含义、理解响应时间和吞吐量的关系、用对测试模型。
TPS和QPS别混用，响应时间和吞吐量是跷跷板，三阶段模型是压测的骨架。这些概念不扎实，后面的调优全是空中楼阁。