性能：怎么理解TPS、QPS、RT、吞吐量这些性能指标

OceanStar的学习笔记

已于 2022-07-06 22:38:01 修改

阅读量6.8k

点赞数 1

分类专栏：计算机理论与基础文章标签：后端

于 2021-11-02 14:22:53 首次发布

原文链接：https://time.geekbang.org/

版权

计算机理论与基础专栏收录该内容

310 篇文章

订阅专栏

性能需求指标

通常我们都从两个层面定义性能场景的需求指标：

业务指标
技术指标

这两个层面需要有映射关系，技术指标不能脱离业务指标。一旦脱离，你会发现你能回答“一个系统在多少响应时间之下能支持TPS”这样的问题，但是回答不了“业务状态是什么”的问题

举例来说，如果一个系统要支持1000万人在线，可能你能测试出来的结果是系统能支持1万TPS，可是如果问你，1000万人在线会不会有问题？这估计就很难回答了

可以根据如下示意图理解业务指标和性能指标之间的关系：

在这里插入图片描述
这个示意显然不够详细，但也能说明关系了。所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。

有了这样的关联关系，下面我们看一下性能测试行业常用的性能指标表示法。
在这里插入图片描述

XPS

误解

QPS一开始是用来MySQL中SQL每秒执行数Query Per Second，所有的SQL都被称为Query。后来，QPS被延伸到压力工具中，用来描述吞吐量，于是这里就有些误解，QPS和TPS到底是什么关系呢？
RPS 指的是每秒请求数。这个概念字面意思倒是容易理解，但是有个容易误解的地方就是，它指的到底是哪个层面的 Request？如果说 HTTP Request，那么和 HPS(Hits Per Second )又有什么关系呢？
HPS，这也是个在字面意思上容易理解的概念。只是 Hit 是什么？有人将它和 HTTPRequest 等价，有人将它和用户点击次数等价。
CPS，用的人倒是比较少，在性能行业中引起的误解范围并不大。同时还有喜欢用CPM（Calls Per Minute，每分钟调用数）的。这两个指标通常用来描述 Service 层的单位时间内的被其他服务调用的次数，这也是为什么在性能行业中误解不大的原因，因为性能测试的人看 Service 层东西的次数并不多。

实例分析

什么是TPS

TPS（Transactions Per Second）用来描述每秒事务数，在不同的行业、不同的业务中定义的粒度都是不同的。
所以不管你在哪里用 TPS，一定要有一个前提，就是所有相关的人都要知道你的 T 是如何定义的。
TPS可以反映出一个系统的处理能力

TPS的粒度

通常情况下，我们会根据场景的目的来定义 TPS 的粒度。

如果是接口层性能测试，T 可以直接定义为接口级；
如果业务级性能测试，T 可以直接定义为每个业务步骤和完整的业务流。

我们用一个示意图来说明一下。
在这里插入图片描述

如果我们要单独测试接口 1、2、3，那 T 就是接口级的；如果我们要从用户的角度来下一个订单，那 1、2、3 应该在一个 T 中，这就是业务级的了。

当然，这时我们还要分析系统是如何设计的。通常情况下，积分我们都会异步，而库存不能异步。所以，这个业务，你可以看成只有1、2两个接口，但是在做这样的业务级压力时，3接口也是必须要监控分析的

所以，性能测试中TPS的T的定义取决于场景的目标和T的作用。一般我们都会这样来定义事务（事务就是统计了一段脚本的执行时间，并没有什么特别的含义）。

接口级脚本：
	——事务 start（接口 1）
	接口 1 脚本
	——事务 end（接口 1）
	——事务 start（接口 2）
	接口 2 脚本
	——事务 end（接口 2）
	——事务 start（接口 3）
	接口 3 脚本
	——事务 end（接口 3）

业务级接口层脚本（就是用业务拼接出一个完整的业务流）
	——事务 start（业务 A）
	接口 1 脚本 - 接口 2（同步调用）
	接口 1 脚本 - 接口 3（异步调用）
	——事务 end（业务 A）

用户级脚本：
	——事务 start（业务 A）
	点击 0 - 接口 1 脚本 - 接口 2（同步调用）
	点击 0 - 接口 1 脚本 - 接口 3（异步调用）
	——事务 end（业务 A）

你要创建什么级别的事务，完全取决于测试的目的是什么。

一般情况下，我们会按从上到下的顺序一一地来测试，这样路径清晰地执行是容易定位问题的。

QPS

QPS，如果它描述的是数据库中的Query Per Second，从上面的示意图来看，其实描述的是服务后面接的数据库中SQL的每秒执行条数。如果描述的是前端的每秒查询数，那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体性能是不够全面的。所以不建议用QPS来模式系统整体的性能，以免误解

RPS（Request per second）

RPS（Request per second），每秒请求数。但是是哪个层面的请求呢？
在这里插入图片描述

如果一个用户点击了一次，发出来 3 个 HTTP Request，调用了 2 次订单服务，调用了 2次库存服务，调用了 1 次积分服务，那么这个 Request 该如何计算？

如果你是算 GDP 的专家，我觉得可能会是：3+2+2+1=8（次）。
而在具体的项目中，我们会单独描述每个服务，以便做性能统计。
如果要描述整体，最多算是有 3 个 RPS。

如果从 HTTP 协议的角度去理解，那么 HTTP Request 算是一个比较准确的描述了，但它本身的定义并没有包含业务。如果赋予它业务的含义，那么用它来描述性能也是可以的。

HPS（Hits Per Second）

HPS（Hits Per Second）每秒点击数

Hit 一般在性能测试中，都用来描述 HTTP Request。
但是，也有一些人用它描述真正的客户在界面上的点击次数

关于这一点，就只有在具体的项目中才能规定得具体一些。当它描述 HTTP Request 时，如果 RPS 也在描述
HTTP Request，那这两个概念就完全一样了。

CPS/CPM

CPS/CPM：Calls Per Second/ Calls Per Minutes，每秒 / 每分钟调用次数。

这个描述在接口级是经常用到的，比如说上面的订单服务。显然一次客户界面上的点击调用两次
但是，在操作系统级，我们也经常会听到系统调用用 call 来形容，比如说用 strace 时，你就会看见 Calls 这样的列名。

小结

这些概念本身并没有问题，但是当上面的概念都用来描述一个系统的性能能力的时候，就混乱了。对于这种情况，我觉得有几种处理方式：

用一个概念统一起来。我觉得直接用 TPS 就行了，其他的都在各层面加上限制条件来描述。比如说，接口调用 1000 Calls/s，这样不会引起混淆
在团队中定义清楚术语的使用层级。
如果没有定义使用层级，那只能在说某个概念的时候，加上相应的背景条件。

所以，当你和同事在沟通性能指标用哪些概念时，应该描述得更具体一些。在一个团队中，应该先有这些术语统一的定义，再来说性能指标是否满足。

响应时间 RT

在性能中，还有一个重要的概念就是响应时间（Response Time）。这个比较容易理解。

我们接着用这张示意图说明：

在这里插入图片描述
RT = T2-T1。计算方式非常直接简单。但是，我们要知道，这个时间包括了后面一连串的链路。

响应时间的概念简单至极，但是，响应时间的定位就复杂了。

性能测试工具都会记录响应时间，但是，都不会给出后端链路到底哪里慢。经常有人问问题就直接说，我的响应时间很慢。问题在哪呢？在这种情况下，只能回答：不知道。

因为我们要先画架构图，看请求链路，再一层层找下去。比如说这样：
在这里插入图片描述
在所有服务的进出口都做记录，然后计算结果就行了。在做网关、总线这样的系统时，基本上都会考虑这个功能。

而现在，随着技术的发展，链路监控工具和一些 Metrics 的使用，让这个需求变得简单了不少。比如说这样的展示：
在这里插入图片描述
它很直观的显式了，在一个请求链路上，每个节点消耗的时间和请求的持续时间。

对于响应时间来说，时间的拆分定位是性能瓶颈定位分析中非常重要的一节。

压力工具中的线程数和用户数与 TPS

在这里插入图片描述
这里先说明一个前提，上面的一个框中有四个箭头，每个都代表着相同的事务。

在说这个图之前，我们需要弄清楚“并发”这个概念是靠什么数据来承载的。你可以说，我的并发是 1000TPS，或者 1000RPS，或者 1000HPS，这都随便你去定义。但是在一个具体的项目中，当你说到并发 1000 这样没有单位的词时，一定要让大家都能理解这是什么。
在上面这张示意图中，其实压力工具是4个并发线程，由于每个线程都可以在1s内完成4个事务，所以总的TPS是16。这非常容易理解吧。而在大部分非技术人的脑子里，这样的场景就是并发数是 4，而不是 16。
要想解释清楚这个非常困难，我的做法就是，直接告诉别人并发是 16 就好了，不用关心 4个线程这件事

那么用户数怎么定义呢？

涉及到用户就比较麻烦一点。因为用户有了业务含义，所以有人认为一个系统如果有1万个用户在线，那就应该测试1万的并发线程，这种逻辑实在是不技术。通常，我们会对在线的用户做并发度分析，在很多业务中，并发度都会低于5%，甚至1%
拿 5% 来计算，就是 10000 用户 x5%=500(TPS)，注意哦，这里是 TPS，而不是并发线程数。如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程)。

通过这样简单的计算逻辑，我们就可以看出来用户数、线程数和 TPS 之间的关系了。

在这里插入图片描述
但是！响应时间肯定不会一直都是 100ms 的嘛。所以通常情况下，上面的这个比例都不会固定，而是随着并发线程数的增加，会出现趋势上的关系。