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. 实际应用示例
性能测试报告中的体现
markdown
**电商系统压测结果**
- **QPS(接口层)**:订单查询API达到 1200 QPS(单接口请求)。
- **TPS(业务层)**:下单支付全链路稳定在 200 TPS(含支付+库存扣减)。
- **瓶颈分析**:当TPS > 200时,数据库CPU达到90%,需优化慢SQL。
如何优化?
- 提高QPS :
- 增加服务器实例(水平扩展)。
- 使用缓存(如Redis减少数据库查询)。
- 提高TPS :
- 优化事务逻辑(如异步处理非核心步骤)。
- 数据库分库分表(降低单表压力)。
5. 面试常见问题
Q:为什么QPS高但TPS低?
- 可能原因 :
- 事务包含复杂业务逻辑(如风控校验)。
- 数据库锁竞争(如秒杀场景)。
- 外部服务调用超时(如第三方支付接口)。
Q:如何设计压测脚本区分QPS和TPS?
- JMeter示例 :
- QPS:直接统计
HTTP Request
的吞吐量。 - TPS:使用
Transaction Controller
将多个请求合并为一个事务。
- QPS:直接统计
6. 总结
- QPS :关注请求吞吐量,适合接口级性能评估。
- TPS :关注业务完整性,适合核心流程性能评估。
- 测试开发价值 :
- 在简历中明确区分两者(如"优化接口QPS从500提升至1200")。
- 分析QPS/TPS瓶颈能体现你的深度性能调优能力。