吞吐量核心指标：QPS、TPS、响应时间、并发数、吞吐量计算公式
聊吞吐量优化，得先搞清楚我们在衡量什么。
很多人一上来就谈「高并发」、「百万 QPS」，但连这几个基础指标都没吃透。我见过不少团队，上线前拍胸脯说能扛 10 万 QPS，结果压测到 5000 就挂了——说白了，指标定义都没对齐。
这一节，我们把吞吐量的五个核心指标掰开揉碎讲清楚。你理解透了，后面的优化才有方向。
2.1 QPS 与 TPS：两个最容易混淆的概念
QPS（Queries Per Second），每秒查询数。它衡量的是系统在一秒内能处理多少个请求。注意，这里的「查询」不一定是数据库查询，它泛指任何一次请求-响应交互。
TPS（Transactions Per Second），每秒事务数。一个事务可能包含多个请求。比如你在电商下单，从加入购物车到支付成功，这整个流程算一个事务，里面可能包含了 5-8 个 QPS。
核心区别：
- QPS 关注单次请求的处理能力
- TPS 关注完整业务流程的处理能力
- 一个 TPS 通常对应多个 QPS
我在项目中遇到过这样的场景：运营同学说「系统 QPS 有 5000，肯定够用」，结果大促时订单系统直接崩了。为什么？因为每个订单事务平均包含 6 个请求，5000 QPS 换算下来只有不到 1000 TPS，根本扛不住真实流量。
| 指标 | 定义 | 典型场景 | 我常用的衡量方式 |
|---|---|---|---|
| QPS | 每秒请求数 | API 网关、静态资源 | Nginx 日志 + 聚合分析 |
| TPS | 每秒事务数 | 订单、支付、转账 | 业务埋点 + 分布式追踪 |
我的习惯：对外汇报用 QPS，对内优化看 TPS。QPS 好看，但 TPS 才是真功夫。
2.2 响应时间：用户感知的「快」与「慢」
响应时间，就是用户发请求到收到响应的时间差。单位通常是毫秒。
但这里有个坑：平均响应时间很容易骗人。我见过一个系统，平均响应时间 200ms，看起来不错对吧？但实际有 30% 的请求超过 2 秒。为什么？因为少数慢请求把平均值拉高了，但大多数用户其实体验很差。
我个人更关注两个指标：
- TP99：99% 的请求在多少毫秒内完成
- TP999：99.9% 的请求在多少毫秒内完成
举个例子：
假设有 1000 个请求，响应时间排序后：
- TP50 = 120ms（一半请求在 120ms 内完成）
- TP90 = 350ms（90% 请求在 350ms 内完成）
- TP99 = 800ms（99% 请求在 800ms 内完成）
- TP999 = 2500ms（99.9% 请求在 2500ms 内完成）你看，平均响应时间可能只有 200ms，但 TP999 已经到 2.5 秒了。这 0.1% 的慢请求，可能就是你的核心用户——比如 VIP 客户的大订单。
避坑指南：我曾经只盯着平均响应时间优化，结果上线后用户投诉「系统卡死了」。查了半天，发现是某个第三方接口偶尔超时，影响了 TP99。从那以后，我压测报告里必须包含 TP99 和 TP999。
2.3 并发数：系统同时能处理多少事
并发数，指的是系统在同一时刻正在处理的请求数量。注意，不是「连接数」，是「正在处理中」的数量。
很多人把并发数和 QPS 搞混。我打个比方：
- 并发数就像餐厅的座位数——同时能坐多少人
- QPS 就像翻台率——每小时能接待多少桌客人
座位数（并发数）固定，翻台率（QPS）越高，总接待量越大。但翻台率受限于上菜速度（响应时间）。
它们的关系很简单：
QPS = 并发数 / 平均响应时间（秒）举个例子：
并发数 = 100，平均响应时间 = 0.2 秒
QPS = 100 / 0.2 = 500反过来，如果你想要 1000 QPS，平均响应时间 0.2 秒，那么并发数至少需要：
并发数 = QPS × 平均响应时间 = 1000 × 0.2 = 200关键结论：并发数不是越高越好。过高的并发数会导致线程竞争、上下文切换开销增大，反而降低 QPS。我习惯在压测时画一条「并发数 vs QPS」曲线，找到那个拐点——就是系统的最佳并发度。
2.4 吞吐量计算公式：把指标串起来
吞吐量，就是系统在单位时间内能处理的总工作量。最常用的公式是：
吞吐量 = 并发数 / 平均响应时间或者更完整的形式：
吞吐量（QPS）= 并发数 × （1 / 平均响应时间）这个公式告诉我们三件事：
- 并发数越大，吞吐量越大——但有限度，超过拐点反而下降
- 响应时间越短，吞吐量越大——这是优化的核心方向
- 两者要平衡——盲目增加并发数，响应时间会飙升
我在实际项目中，通常用这个公式做容量评估：
预估 QPS = （目标并发数 × 1000） / 预估响应时间（ms）
举例：
目标并发数 = 500，预估响应时间 = 50ms
预估 QPS = （500 × 1000） / 50 = 10000我的经验：这个公式算出来的是理论最大值。实际能跑到的 QPS 通常是理论值的 60%-80%。所以做容量规划时，我会留 30% 的余量。
2.5 指标之间的关系：一张图看懂
下面这张图，把五个核心指标的关系画清楚了。你盯着看两分钟，就能理解吞吐量的本质。
2.6 实战中如何用这些指标
光知道定义没用，得会用。我分享几个实战场景：
场景一：压测报告怎么看
拿到一份压测报告，我第一眼看 TP99，第二眼看并发数曲线。如果 TP99 超过 500ms，或者并发数超过 200 后 QPS 不再增长，说明系统瓶颈到了。
场景二：容量规划怎么做
假设业务预估峰值流量是 5000 QPS，平均响应时间目标 100ms。那么：
所需并发数 = 5000 × 0.1 = 500
考虑 30% 余量，实际需要 650 并发然后根据这个并发数，去评估线程池大小、数据库连接池大小、服务器数量。
场景三：优化效果怎么衡量
我习惯用「吞吐量提升百分比」来衡量优化效果：
优化前 QPS = 2000，优化后 QPS = 3200
提升 = (3200 - 2000) / 2000 × 100% = 60%注意，要保证并发数和响应时间分布一致，否则对比没有意义。
我曾经踩过的坑：有一次优化后 QPS 从 3000 涨到 4500，我高兴坏了。结果仔细一看，压测时并发数从 200 调到了 400。这不是优化，这是堆资源。真正的优化，是在相同并发数下提升 QPS，或者在相同 QPS 下降低响应时间。
2.7 小结：记住这五件事
- QPS：每秒请求数，看系统能接多少活
- TPS：每秒事务数，看系统能完成多少业务
- 响应时间：别只看平均，盯住 TP99 和 TP999
- 并发数：找到最佳拐点，不是越大越好
- 吞吐量公式：吞吐量 = 并发数 / 平均响应时间，这是所有优化的起点