什么是QPS，什么是RT？

好的！我们来更加 细致深入地探讨 QPS 和 RT 这两个关键性能指标，包括它们的 精确定义、计算方式、相互关系、实际应用场景、影响因素、优化思路，以及它们在 系统设计、性能压测、容量评估 中是如何被使用和关联的。

---

一、QPS（Queries Per Second）—— 每秒查询数 / 请求数

1. 定义（精准版）

QPS（Queries Per Second） 是指 系统在单位时间（1秒）内成功处理的请求数量，是衡量一个服务接口或系统整体 吞吐能力（Throughput） 的核心指标之一。

注意：

• 严格来说，“Query” 原意是“查询”，但在实际工程中，QPS 往往泛指各种类型的请求，不仅限于查询，也包括一些简单的写操作。
• 如果涉及事务性操作（如订单创建、支付等涉及多个步骤的操作），更准确的指标可能是 TPS（Transactions Per Second，每秒事务数）。

---

2. 计算方式

（1）基本公式：

$$QPS=\frac{\text{总请求数}}{\text{总时间（秒）}}$$

（2）举例：

• 某个接口在 60 秒内处理了 12000 个请求，那么：
  $$QPS=\frac{12000}{60}=200\text{ QPS}$$
  也就是说，该接口的吞吐能力为每秒 200 次请求。

• 如果你用压测工具（如 JMeter、wrk、Locust）打流量，工具一般都会直接统计出 QPS。

---

3. 相关概念辨析

指标	全称	说明	适用场景
QPS	Queries Per Second	每秒查询请求数，适用于读多写少的接口	查询类服务，如商品详情、搜索
TPS	Transactions Per Second	每秒事务数，一个事务可能包含多个操作（如数据库事务）	订单、支付等强一致性业务
CPS	Calls Per Second	每秒调用次数，与 QPS 类似，有时用于 RPC 调用统计	微服务间调用
RPS	Requests Per Second	每秒请求数，与 QPS 几乎同义	通用请求统计

实际工作中，QPS 和 RPS 经常混用，但如果你强调是“查询”，用 QPS 更准确；如果是综合请求，RPS 也是可以的。

---

二、RT（Response Time）—— 响应时间

1. 定义（精准版）

RT（Response Time） 是指从 客户端发起请求的时刻开始，到接收到服务端完整响应的时刻为止，所经历的时间，单位通常是 毫秒（ms）。

也可以理解为：用户感知的系统处理速度。

---

2. 常见细分指标

在实际监控和性能分析中，RT 可以进一步细分，用来更精准定位问题：

类型	说明	用途
平均响应时间 (Avg RT)	所有请求 RT 的平均值	整体性能的粗略判断
最大响应时间 (Max RT)	所有请求中最慢的一次	发现极端情况
最小响应时间 (Min RT)	所有请求中最快的一次	理论最优情况参考
P50 / P90 / P95 / P99 RT	百分位响应时间，例如 P99 表示 99% 的请求都在该时间内返回	重点关注长尾请求，用户体验关键指标
TP99（Time Percentile 99）	即 P99，常用于高并发系统衡量服务质量

✅ P99 响应时间比平均响应时间更能体现用户真实体验，因为平均可能被大量快速请求拉低，而少数慢请求拖垮用户体验。

---

3. 举例

假设对某接口进行了 1000 次请求，得到如下响应时间（单位：ms）：

• 900 个请求在 50ms 内返回
• 90 个请求在 200ms 内返回
• 10 个请求在 800~2000ms 返回

那么：

• 平均 RT ≈ （900×50 + 90×200 + 10×1000）/ 1000 ≈ 105ms
• 但 P99 RT 可能高达 1500ms，意味着 1% 的用户会感觉到明显卡顿

➤ 所以在高并发、高可用架构中，P99、P95 等响应时间非常关键！

---

三、QPS 与 RT 的关系（核心重点！）

QPS 和 RT 是衡量系统性能的两个维度，二者存在紧密的数学关系与实际影响。

---

1. 数学关系（简化模型）

在理想情况下，如果系统是 线性、稳定、无队列堆积、无瓶颈 的，那么：

$$\text{QPS}\approx \frac{\text{并发数}}{\text{RT（秒）}}\text{或}\text{并发数}\approx \text{QPS}\times \text{RT（秒）}$$

举个例子：

• 假设平均响应时间 RT = 100 毫秒 = 0.1 秒
• 你想支持 1000 QPS（每秒 1000 个请求）

那么：
$$\text{并发数}\approx 1000\times 0.1=100$$

也就是说，系统大概需要同时处理 100 个请求，才能达到 1000 QPS 的吞吐量。

---

2. 实际中的相互制约

场景	QPS 高 / RT 低	QPS 高 / RT 高	QPS 低 / RT 低	QPS 低 / RT 高
表现	系统健康，用户体验好	系统负载高，用户感知卡顿	系统较空闲，响应快	系统可能出了问题，如阻塞、死锁
原因	代码高效、资源充足、缓存合理	可能资源不足、慢查询、锁竞争、GC 频繁	流量小，系统轻松应对	接口异常、下游服务慢、数据库瓶颈等
优化方向	继续保持，做好监控	优化慢请求、扩容、异步化、降级	无需特别优化	排查慢根因，如 DB、网络、代码逻辑

---

3. 压测中的实际表现

在进行压力测试时，我们通常会逐步增加并发用户数（或 QPS），然后观察：

• 系统的 QPS 上限是多少？
• 当 QPS 增加时，RT 是平稳、缓慢上升，还是急剧上升？
• 当 RT 开始显著增加时（比如超过 500ms 或 1s），往往意味着系统资源已经出现瓶颈。

📌 经验法则：

• 当 RT 开始非线性增长时，QPS 很难再提升，甚至会下降（系统过载保护、排队、拒绝服务等机制触发）。
• 一个健康的服务，应该保证在目标 QPS 下，RT 依然处于可接受范围（比如 < 200ms ~ 500ms）。

---

四、QPS 与 RT 的工程意义与应用

---

1. 性能评估 & 服务容量规划

在系统上线前或扩容前，我们通常会做 性能压测（Load Test / Stress Test），目的是得出：

• 在多少 QPS 下，RT 能保持在目标范围内（如 ≤ 200ms）？
• 系统的最大承载 QPS 是多少？
• 多少台机器 / 多少实例能支撑预期的业务流量？

🔧 常用工具：

• JMeter
• wrk
• Locust
• Gatling
• Nginx/Apisix 访问日志分析
• Prometheus + Grafana 监控

---

2. 监控与告警

在生产环境中，我们需要实时监控服务的：

• 实时 QPS：当前流量是否正常，是否突发流量
• 实时 RT：特别是 P90、P99，看是否有慢请求增多
• 错误率（Error Rate）：如 HTTP 5xx、超时、异常比例

一旦发现 QPS 暴增但 RT 飙升，或者错误率升高，就需要快速告警与干预！

---

3. 优化方向参考

目标	优化手段
提升 QPS	1. 代码优化（减少计算/IO） 2. 引入缓存（Redis等） 3. 数据库索引优化、读写分离 4. 服务无状态化，方便横向扩展 5. 异步化（MQ削峰） 6. 负载均衡，多实例部署
降低 RT	1. 减少网络往返（如合并请求） 2. 优化慢 SQL、减少 IO 操作 3. 使用缓存预热、避免穿透 4. 优化算法与数据结构 5. 减少锁竞争、优化线程池 6. CDN / 静态资源加速
保障稳定性	1. 限流（令牌桶、漏桶） 2. 熔断降级（Hystrix/Sentinel） 3. 服务隔离与分组 4. 自动扩缩容（K8s + HPA）

---

五、总结表格（终极版）

指标	全称	单位	定义	关注点	优化目标
QPS	Queries Per Second	次/秒	每秒处理的请求数	系统吞吐能力、并发处理能力	越高越好（在一定 RT 范围内）
RT	Response Time	毫秒（ms）	请求从发起到返回的总耗时	用户体验、系统性能	越低越好（一般 < 200~500ms）

关系公式：
$$QPS\propto \frac{\text{并发能力}}{RT}\text{或}并发数\approx QPS\times RT(秒)$$

---