QPS、TPS、吞吐量的思考

目录

无论前后端,大家在提到性能时总爱用 QPS,这样表达性能合理吗?

QPS 与 TPS,它们的区别是什么?

本文围绕这些问题展开。

是什么

  • QPS
    • Query Per Second 每秒查询数量,最初是用在表示数据执行每秒执行的 SQL 数,表示数据的查询能力,现在已经是一个通用名词了
  • TPS
    • Transactions Per Second 每秒事务数。事务大家很熟悉,就是一组操作要么完成要么失败,TPS 就是表示这种事务单元的处理能力。
    • 它的意义在于表达完成某件事的能力
      • 后端角度,通常表示业务接口的性能。比如创建工单接口,该接口是写接口,读写 db,并且在创建完毕后给负责任发消息,这是一组操作集合,它的 TPS 代表了系统创建工单的能力上限。
      • 前端角度,一批接口的性能,往往代表系统用户承载量。
  • 吞吐量/吞吐率
    • 系统的吞吐量(承压能力)与 request 对 CPU 的消耗、外部接口、IO 等等紧密关联。单个 request 对 CPU 消耗越高,外部系统接口、IO 速度越慢,系统吞吐能力越低,反之越高。
    • 经常用 QPS、TPS 表示

一梭子都用 QPS 的合理与不合理

首先,QPS 是一个很简单的概念,很好理解。站在前后端的角度就是在一秒内接口能查几次,表示接口的性能好理解。看板和基础组件统计数据时,通常也是接口的粒度,接口调用次数、P99 耗时等,这些工具渗透到了大家的日常,无形中引导大家使用 QPS 来进行表达。

对于后端来讲,接口是业务的功能单元,它背后是一组操作,读写 DB 或者进行远程调用(RPC)。如果是读接口,用 QPS 还有些合理,但是写接口就不太合理了,因为插入、更新会开启 DB 事务。

个人认为,在后端,接口使用 TPS 更符合一些,因为它表达了完成一件事。

QPS 和 TPS 比较

QPS 基本类似于 TPS,但是不同的是,对于一个页面的一次访问,形成一个 TPS,即一个 T 会产生多个 Q

吞吐量

系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间。

  • QPS(TPS):Query Per Second 每秒钟 request或事务的数量
  • 并发数:系统同时处理的request或事务数
  • 响应时间:一般取平均响应时间

理解了上面三个要素的意义之后,就能推算出它们之间的关系:

  • QPS(TPS)= 并发数/平均响应时间
  • 并发数 = QPS*平均响应时间

容量预估

单接口 QPS 可以压测得到。

通过流量预估 QPS 时,可以采用二八定律,每天 80%的访问集中在 20% 的时间里,这 20% 的时间叫做峰值时间。

  • 公式:(总 PV 数 * 80%)/(每天秒数 * 20%) = 峰值时间请求 QPS
  • 机器:峰值时间每秒 QPS / 单机器的 QPS = 需要的机器

需要注意,我们应该取线上的真实指标作为公式输入,公式里 20% 为高峰并不适用所有系统,评估系统容量时即使 10x 冗余也不过分,应该考虑真实的业务场景,比如服务重要性、保障等级、可承受的损失等。

参考、其他资源