一、吞吐分析概述：什么是吞吐量、为什么需要吞吐分析、吞吐分析的应用场景
大家好，我是这次课程的主讲。咱们直接进入正题——吞吐分析。
说实话，我做了这么多年性能测试，见过太多团队一上来就盯着响应时间猛调，结果系统压测一跑，TPS上不去，CPU还跑满了。嗯，这就是典型的「只盯着延迟，忽略了吞吐」。
今天这一章，咱们就把吞吐量这个概念彻底聊透。我会结合我踩过的坑，给你讲清楚：吞吐量到底是什么、为什么它比响应时间更关键、以及你在哪些场景下必须做吞吐分析。
1.1 什么是吞吐量？
先给个最直白的定义：吞吐量，就是系统在单位时间内能处理多少请求或数据量。
你想想看，一个电商网站的双十一大促，用户点一下「下单」，后端要处理多少事情？数据库写入、库存扣减、支付回调……所有这些操作加在一起，系统每秒能完成多少次，这就是吞吐量。
常见的吞吐量指标有这些：
| 指标名称 | 含义 | 常用单位 |
|---|---|---|
| TPS（Transactions Per Second） | 每秒完成的事务数 | 笔/秒 |
| QPS（Queries Per Second） | 每秒完成的查询数 | 次/秒 |
| RPS（Requests Per Second） | 每秒完成的请求数 | 个/秒 |
| 吞吐带宽 | 网络或磁盘每秒传输的数据量 | MB/s、Gb/s |
我个人习惯，在接口性能测试中，最常用的是 TPS 和 QPS。这两个指标能直接反映系统的处理能力。
核心要点：吞吐量不是越高越好，而是要在满足响应时间要求的前提下，尽可能高。说白了，就是「又快又多」。
1.2 为什么需要吞吐分析？
这个问题我问过不少刚入行的朋友。很多人觉得：「我只要把接口调快了，吞吐量自然就上去了。」
其实不然。我在项目中遇到过这样一个案例：一个支付系统的核心接口，响应时间从 200ms 优化到了 50ms，按理说吞吐量应该翻 4 倍对吧？结果一压测，TPS 只提升了 30%。
为什么会这样？
因为系统的瓶颈根本不在代码执行速度上，而在数据库连接池的配置上。连接池太小，线程都在排队等连接，代码再快也没用。
所以，吞吐分析的核心价值在于：
- 发现系统瓶颈——到底是 CPU 不够、内存不足、还是 IO 卡住了？
- 评估系统容量——你的系统到底能扛多少并发用户？
- 指导扩容决策——是加机器还是加配置？加多少？
- 验证优化效果——你改的代码到底有没有用？
我的经验：每次做性能优化之前，先跑一轮吞吐分析，把瓶颈找出来。否则你优化了半天，可能只是在「优化一个不存在的瓶颈」。
1.3 吞吐分析的应用场景
吞吐分析不是实验室里的理论，它每天都在真实的生产环境中发挥作用。我把它归纳为三大类场景：
场景一：上线前的容量评估
新系统上线前，必须知道它能扛多少流量。我记得有一次给一个金融系统做压测，目标 TPS 是 5000。结果一跑，到 3000 就崩了。后来发现是 Redis 集群的 maxclients 配置没调。如果没有提前做吞吐分析，上线那天就是事故现场。
场景二：线上故障排查
线上突然变慢了，用户反馈「转圈圈」。这时候吞吐分析能帮你快速定位：是流量突增导致系统过载？还是某个服务挂了导致吞吐量骤降？
场景三：日常性能监控与优化
吞吐量不是测一次就完事的。系统在运行过程中，随着数据量增长、代码迭代、配置变更，吞吐量会动态变化。我建议把吞吐量指标纳入日常监控大盘，设置告警阈值。一旦吞吐量出现异常下降，立刻排查。
下面这张图，是我自己总结的吞吐分析知识体系，你可以对照着看：
注意：千万不要把吞吐分析和压力测试混为一谈。吞吐分析是持续性的、系统性的工作，而压力测试只是其中的一个手段。我曾经见过有人压测跑了一轮，看到 TPS 达标就以为万事大吉了——结果上线后数据量一涨，吞吐量直接腰斩。
好了，这一章的内容就到这里。吞吐量这个概念虽然基础，但它是整个性能测试的基石。后面的章节，我会带你一步步深入，从工具使用到实战分析，把吞吐分析彻底吃透。