QPS 和 TPS 详解

QPS 和 TPS 是性能测试中的两个核心指标，用于衡量系统的吞吐能力，但关注点不同。以下是具体解析：

---

1. QPS（Queries Per Second）

定义：每秒查询数，表示系统每秒能处理的请求数量（无论请求是否成功）。
适用场景：

• Web服务：如API接口、HTTP请求。
• 缓存/数据库：如Redis的GET/SET操作。

计算公式：

QPS = 总请求数 / 测试时间（秒）

示例：

• 一个HTTP接口在10秒内收到5000次请求，则 QPS = 5000 / 10 = 500。

---

2. TPS（Transactions Per Second）

定义：每秒事务数，表示系统每秒能完成的事务数量（一个事务可能包含多个请求）。
适用场景：

• 业务链路的性能：如支付流程（包含下单、支付、通知等多个步骤）。
• 数据库事务：如银行转账（扣款+入款需保证原子性）。

计算公式：

TPS = 成功的事务数 / 测试时间（秒）

示例：

• 一个支付流程（包含3个API调用）在1分钟内完成1200笔交易，则 TPS = 1200 / 60 = 20。

---

3. QPS 和 TPS 的关系

对比维度	QPS	TPS
粒度	单次请求	完整业务流（可能含多请求）
成功要求	统计所有请求（含失败）	仅统计成功完成的事务
典型场景	接口压测、缓存性能测试	支付、订单等业务场景

常见关联：

• 若一个事务包含N个请求，则 QPS ≈ TPS × N（假设无失败请求）。
• 例如：支付事务包含3个API调用（下单、支付、回调），当TPS=100时，QPS可能接近300。

---

4. 实际应用示例

性能测试报告中的体现

**电商系统压测结果**  
- **QPS（接口层）**：订单查询API达到 1200 QPS（单接口请求）。  
- **TPS（业务层）**：下单支付全链路稳定在 200 TPS（含支付+库存扣减）。  
- **瓶颈分析**：当TPS > 200时，数据库CPU达到90%，需优化慢SQL。  

如何优化？

• 提高QPS：
  • 增加服务器实例（水平扩展）。
  • 使用缓存（如Redis减少数据库查询）。
• 提高TPS：
  • 优化事务逻辑（如异步处理非核心步骤）。
  • 数据库分库分表（降低单表压力）。

---

5. 面试常见问题

Q：为什么QPS高但TPS低？

• 可能原因：
  1. 事务包含复杂业务逻辑（如风控校验）。
  2. 数据库锁竞争（如秒杀场景）。
  3. 外部服务调用超时（如第三方支付接口）。

Q：如何设计压测脚本区分QPS和TPS？

• JMeter示例：
  • QPS：直接统计HTTP Request的吞吐量。
  • TPS：使用Transaction Controller将多个请求合并为一个事务。

---

6. 总结

• QPS：关注请求吞吐量，适合接口级性能评估。
• TPS：关注业务完整性，适合核心流程性能评估。
• 测试开发价值：
  • 在简历中明确区分两者（如“优化接口QPS从500提升至1200”）。
  • 分析QPS/TPS瓶颈能体现你的深度性能调优能力。