性能测试：常见性能测试指标 -- 吞吐量

性能测试：常见性能测试指标 – 吞吐量

这篇博客，是从这篇博客的内容中，分离出来的，用来介绍性能测试的。
上一篇博客： 测试(12) - 性能测试概念篇

如果你没有看过上一篇博客，推荐看到上一篇博客中，这篇博客的链接后，再点击那个链接，进来看这篇博客。

1. 事务

在性能测试中，会遇到一个概念：事务（Transaction）
事务可以简单理解为：一个完整的功能或者一个完整的业务操作。

例如：

• 一个接口可以是一个事务
• 多个接口可以组成一个事务
• 一个完整的业务流程也可以是一个事务

所以：事务代表一个完整的功能。

例如一个“用户下单”的业务流程可能包含：

1. 查询商品
2. 创建订单
3. 扣减库存
4. 支付
5. 返回订单结果

如果我们把整个“下单”过程作为一个完整业务，那么整个流程就可以看成一个事务。

2. 什么是吞吐量？

吞吐量指的是：单位时间内系统处理的请求、事务或数据量。
吞吐量可以直接体现软件系统的负载承受能力。

通常来说：吞吐量越高，系统能够承受的并发请求越多，性能越好。

3. 吞吐量案例

假设有 A、B 两种场景。

3.1 A 场景

有 100 个并发用户，每个用户每隔 1 秒发送一个请求
即1s 有100个用户分别发送了请求，总共发送了100 × 1 = 100个请求
所以 A 场景的吞吐量为：每秒 100 个请求

3.2 B 场景

有1000 个并发用户，每个用户每隔 10 秒发送一个请求
即10s 有1000个用户分别发送了请求，总共发送了1000 × 10 = 10000个请求
那么1s 中，发送的请求数量为：1000 ÷ 10 = 100
所以 B 场景的吞吐量同样是：每秒 100 个请求

因此：A 和 B 两个场景的吞吐量相同，都是每秒 100 个请求。

3.3 区别：

但是，两者对系统资源的占用情况并不完全相同。

A 场景用户的思考时间更短，因此 A 场景会占用更多的系统资源。

3.4 解释：为什么A场景会占用更多的系统资源

A 场景的人虽然少，但是操作特别频繁，所以服务器一直在忙。

比如把服务器想象成餐厅老板：

• A：100 个顾客，每 1 秒来点一次菜
  • 顾客少，但是不停点菜
  • 老板一直在忙
• B：1000 个顾客，每 10 秒才点一次菜
  • 顾客多，但是点菜没那么频繁，可以休息一下
  • 老板有更多空闲时间

虽然两种情况：平均每秒都是 100 个订单
但是 A 的顾客操作得更频繁，所以服务器可能一直处于忙碌状态。

所以你只需要记住：思考时间越短 → 用户操作越频繁 → 服务器越忙 → 资源占用可能越高。

所以，在性能测试中：不能只看吞吐量一个指标，还需要结合并发用户数、响应时间、资源利用率等指标进行综合分析。

4. 吞吐量分类：

吞吐量分类：

1. 按照请求数量：TPS 和 QPS
2. 按照网络数据包划分：KB / 每秒

下面主要讲 TPS 和 QPS。

4.1 TPS

TPS 全称：Transactions Per Second
中文：每秒处理事务数

TPS 用来衡量系统在一定时间内能够处理多少个事务。
计算公式：TPS = 总的事务数 ÷ 总的运行时间

TPS 案例

例如：某系统 1 分钟处理了 1000 个业务。
那么：TPS = 1000 ÷ 60 ≈ 16.7
也就是说：这个系统平均每秒可以处理约 16.7 个事务。

TPS 预测案例

假设：2022 年最高的一天有 10 万笔交易。
如果认为每笔交易就是一个事务，一天有24个小时，一个小时60分钟，一个分钟有60秒
那么理论 TPS：TPS = 100000 ÷ 24 ÷ 60 ÷ 60 ≈1.2 TPS

但这个结果只是理想状态。
因为真实业务并不是平均分布在 24 小时中的。
例如购物网站中，订单可能集中在某几个时间段产生。

所以实际进行性能容量规划时，需要考虑业务高峰期。

• 没有详细业务数据怎么办？

如果没有更加详细的数据，可以根据：二八定律，进行估算。

还是按照这个例子：2022 年最高的一天有 10 万笔交易。

也就是：80% 的事务在 20% 的时间内完成。

按照这个方式进行估算：TPS = 100000 × 0.8 ÷（24 × 60 × 60 × 0.2）≈4.6 TPS

• 有详细业务数据怎么办？

如果有更加详细的业务数据，那么可以直接根据高峰期的数据进行计算。
例如：5 万笔交易集中在晚上的 8 点～9 点完成。
那么：TPS = 50000 ÷ 60 ÷ 60 ≈13.9 TPS

如果进一步考虑业务增长。
假设：每年的业务增长率为 30%。
那么：TPS = （50000 + 50000 × 0.3）÷ 60 ÷ 60 ≈18 TPS

因此，在实际进行 TPS 规划时：不能简单地使用全天平均数据，还需要结合业务高峰期以及未来业务增长情况进行分析。

4.2 QPS

QPS 全称：Queries Per Second
中文：每秒查询率

QPS主要用于衡量系统每秒能够处理多少个查询请求。
这里的“查询”不一定只是我们平时理解的“查询数据库”，而是主要强调查询类请求。

例如：一个商品查询接口：

GET /product/1001

用户每秒访问这个接口 100 次，那么：QPS = 100
也就是说：系统每秒处理了 100 个查询请求。

QPS 案例

假设一个商品列表查询接口：1 分钟一共处理了 6000 次查询请求。
那么：QPS = 6000 ÷ 60 = 100
所以：QPS = 100

也就是说，这个接口平均每秒能够处理100 个查询请求。

4.3 TPS 和 QPS 的区别

TPS 和 QPS 都是用来衡量系统单位时间内处理请求的能力，但是两者关注的对象不同。

简单理解：TPS 看“事务”，QPS 看“查询”。

例如一个“下单”业务：

查询商品 ↓ 创建订单 ↓ 扣减库存 ↓ 支付 ↓ 完成订单

我们可以把整个“下单”流程看成：1 个事务

那么完成100 个下单业务：TPS = 100 / 秒

但是这个下单业务过程中可能产生多个查询请求。

例如：

查询商品 → 1 次查询 查询库存 → 1 次查询 查询订单 → 1 次查询

这些查询请求就可以用QPS来衡量。

---

最简单的区别

指标	全称	主要衡量
TPS	Transactions Per Second	每秒处理多少个事务
QPS	Queries Per Second	每秒处理多少个查询请求

可以直接记成：

• TPS：每秒完成多少个业务。
• QPS：每秒处理多少个查询。

---

4.4 TPS 和 QPS 的关系

如果：一个事务中只有一个接口，并且这个接口是查询接口
那么：QPS = TPS

例如：一个查询商品的业务只有一个查询接口。
每秒完成 100 次查询：

TPS = 100 QPS = 100

但是，如果一个事务中包含多个查询请求，那么：QPS 就可能大于 TPS。
例如：一个业务事务平均需要执行5 个查询请求。
每秒完成 100 个事务：

TPS = 100 QPS = 100 × 5 = 500

也就是说：100 个业务事务，每秒可能产生 500 个查询请求。

所以，在性能测试中，TPS 和 QPS 不能简单地认为是同一个东西。

4.5 总结：

TPS主要看系统每秒能完成多少个业务事务，
QPS主要看系统每秒能处理多少个查询请求。

对于面试来说，可以记住：
TPS → 事务
QPS → 查询
1 个事务 = 1 个查询接口时，QPS = TPS。

5. 结尾

最后，如果这篇博客能帮到你的，请你点点赞，有写错了，写的不好的，欢迎评论指出，谢谢！

回到性能测试博客：测试(12) - 性能测试概念篇