1. 吞吐量概念与性能指标理解
1.1 什么是吞吐量？
吞吐量这个词，我在项目中听过太多次了。说白了，就是系统在单位时间内能处理多少请求。比如一个支付接口，每秒能完成100笔交易，那它的吞吐量就是100 TPS。
但要注意，这个数字不是拍脑袋定的。它跟硬件配置、代码效率、中间件瓶颈都强相关。我见过不少团队，看监控里CPU才30%，就以为系统很闲——结果一压测，吞吐量早到天花板了。为什么会这样？后面我们会详细讲。
1.2 常见的吞吐量度量单位
不同场景用不同单位，别混用。我个人习惯这样区分：
| 单位 | 全称 | 典型场景 |
|---|---|---|
| QPS | Queries Per Second | 读接口、DB查询、搜索 |
| TPS | Transactions Per Second | 支付、下单、核心事务 |
| RPS | Requests Per Second | 通用HTTP请求 |
| HPS | Hits Per Second | 静态资源、CDN |
你想想看，如果一个下单操作需要查库存、扣余额、写订单，那它其实是1个事务里包了多次请求。这时候TPS比QPS更贴切。
1.3 吞吐量与延迟、并发的关系
这三者就像三角形的三个顶点，动一个其他都跟着变。我最早做性能测试时，以为堆高并发就能提高吞吐量，结果延迟暴涨，系统直接崩了。后来看了一句话才明白：
吞吐量 = 并发数 / 平均响应时间。
当然，这只是简化公式。实际系统还有排队、锁竞争、内存抖动等因素。但记住这个基本关系，能帮你快速定位方向。
- 并发数上升 → 吞吐量先升后平 → 最终下降（拐点就是瓶颈）
- 降低响应时间 → 同等并发下吞吐量提升
- 延迟抖动 → 实时的瞬时吞吐量大幅下降
我的经验： 不要只看平均响应时间，要看TP99甚至TP999。有一次压测，平均响应时间只有30ms，但TP99已经800ms了。结果用户投诉卡顿，我们却一直盯着平均值优化，方向完全错了。
1.4 关键性能指标清单
除了吞吐量本身，以下指标你必须理解清楚：
- 平均响应时间 (Avg RT) —— 最直观，但容易被极端值拉偏。
- 百分位响应时间 (TP50/TP90/TP99) —— 我建议重点关注TP99，它代表绝大多数用户体验。
- 最大响应时间 (Max RT) —— 偶发飙高可能是GC、慢SQL或网络抖动。
- 错误率 (Error Rate) —— 压测时错误率超过1%就得立即停止分析。
- 并发用户数 (Concurrency) —— 注意跟“在线用户数”是两码事。
- CPU/内存/IO 利用率 —— 资源侧必须配合解读。
核心公式： 系统吞吐量的理论上限 = 1 / ( 平均响应时间 × 资源占用系数 )，实际还受锁、队列长度、网络带宽影响。
1.5 性能指标体系（一张图说清楚）
下面这张图概括了我个人对吞吐量相关指标的理解。中心是吞吐量，左边是前置因素（并发、延迟），右边是衍生指标，下方是底层资源影响。
图里你可以看到，吞吐量不是孤立指标。想提升它，要么提高并发，要么降低响应时间；而底层资源（CPU、内存、IO）又是硬约束。实际压测时，我通常会同时采集这几个维度的数据，对照着看。
1.6 避坑指南
我曾经踩过的坑： 有一次压测一个订单服务，我把并发数从100加到500，吞吐量从500涨到800但延迟从20ms涨到200ms。我以为是正常衰减，直到把TP99拿出来看——已经3秒了！原来数据库连接池太小，大量线程在排队。如果只看平均响应时间，根本发现不了。
所以这里给三条建议：
- 压测时同时记录吞吐量、响应时间百分位、错误率，三者缺一不可。
- 先小并发预热（比如5~10并发），等系统稳定再逐步加压。
- 当吞吐量出现“平台”甚至下降时，立刻检查资源使用率和锁竞争，往往能找到瓶颈。
1.7 本章小结
吞吐量是你系统能力的直接体现，但千万别只盯着一个数字。你得理解并发、延迟、资源之间的关系，学会用TP99、错误率等指标去交叉验证。我个人觉得，性能测试不是跑个结果就完事，而是通过数字去理解系统内部到底发生了什么。接下来的章节，我们会在压测环境里把这些指标一个个验证，你很快就能上手。