怎么理解 TPS、QPS、RT、吞吐量这些性能指标
文章目录
- 理解那些性能指标概念
- 响应时间 RT
- 每秒事务数量 TPS
- 每秒查询数 QPS
- 每秒请求数 QPS
- 吞吐量
- 每秒点击数 HPS
- 每秒 / 每分钟调用次数 CPS/CPM
- 压力工具中的线程数和用户数与 TPS
- 业务模型
- 响应时间如何设置
- 小结
两个层面定义性能场景的需求指标：业务指标和技术指标。
所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。
常见性能指标：
理解那些性能指标概念
响应时间 RT
Response Time。可以简单理解为：网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间
从一个实例中理解：
RT = T2 - T1 。计算方式似乎容易，但是响应时间的定位就比较复杂了。因为性能测试工具都会记录响应时间，但是，都不会给出后端链路到底哪里慢。
从这个简单架构图来看请求链路：
在所有服务的进出口都做记录，然后计算结果，在网关、总线这样的系统都会考虑这个功能。现在的一些链路监控工具和一些 Metrics 的使用可以完成需求，他会记录每一个请求链路上每个节点消耗时间和请求的持续时间。
每秒事务数量 TPS
Transations Per Second。而这个 TPS 中的 T 需要有一个明确理解
通常情况下，我们会根据场景的目的来定义 TPS 的粒度。如果是接口层性能测试，T 可以
直接定义为接口级；如果业务级性能测试，T 可以直接定义为每个业务步骤和完整的业务
流。
用图示简单说明下：
如果我们要单独测试接口 1、2、3，那 T 就是接口级的；如果我们要从用户的角度来下一
个订单，那 1、2、3 应该在一个 T 中，这就是业务级的了
当然，这时还要分析系统是如何设计的。通常情况下，积分都会异步，而库存不能异步。所以这个业务，可以看成只有 1、2 两个接口，但是在做这样的业务级压力时，3 接口也是必须要监控分析的。
所以，性能中 TPS 中 T 的定义取决于场景的目标和 T 的作用。可以这样来定事务
要创建什么级别的事务，完全取决于测试的目的。一般可以从上到下的顺序一一地来测试，这样路径清晰地执行是容易定位问题
搞清楚了 TPS 的 T 是什么，那其实 TPS 就是字面意思：每秒事务数。在性能测试过程中，TPS 之所以重要，是因为它可以反应出一个系统的处理能力。
每秒查询数 QPS
它描述的是数据库中的 Query Per Second，从上面的示意图中来看，其实描述的是服务后面接的数据库中 SQL 的每秒执行条数。如果描述的是前端的每秒查询数，那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是不够全面的。所以不建议用 QPS 来描述系统整体的性能，以免产生误解
每秒请求数 QPS
Request per second，每秒请求数。对于请求数来说，要看是在哪个层面看到的请求，因为请求这个词，实在是太泛了。我们把上面的图做一点点变化来描述一下请求数
如果一个用户点击了一次，发出来 3 个 HTTP Request，调用了 2 次订单服务，调用了 2
次库存服务，调用了 1 次积分服务，那么这个 Request 该如何计算？
在具体的项目中，我们会单独描述每个服务，以便做性能统计。如果要描述整体，最多算是有 3 个 RPS。如果从 HTTP 协议的角度去理解，那么 HTTP Request 算是一个比较准确的描述了，但它本身的定义并没有包含业务。如果赋予它业务的含义，那么用它来描述性能也是可以的
吞吐量
吞吐量是指系统在单位时间内处理请求的数量，用于衡量网络性能或软件性能,TPS、QPS都是吞吐量的常用量化指标。
一个系统的吞吐量（承压能力）与request（请求）对cpu的消耗，外部接口，IO等等紧密关联。
单个request 对cpu消耗越高，外部系统接口，IO影响速度越慢，系统吞吐能力越低，反之越高。
每秒点击数 HPS
Hits Per Second，每秒点击数。Hit 一般在性能测试中，都用来描述 HTTP Request。但是，也有一些人用它描述真正的客户在界面上的点击次数。关于这一点，就只有在具体的项目中才能规定得具体一些。当它描述 HTTP Request 时，如果 RPS 也在描述HTTP Request，那这两个概念就完全一样了
每秒 / 每分钟调用次数 CPS/CPM
Calls Per Second/ Calls Per Minutes 。这个描述在接口级是经常用到的，比如说上面的订单服务。显然一次客户界面上的点击调用两次。这个比较容易理解。但是，在操作系统级，我们也经常会听到系统调用用 call 来形容，比如说用 strace 时，你就会看见 Calls 这样的列名。
这些概念本身并没有问题，但是当上面的概念都用来描述一个系统的性能能力的时候，就混
乱了。对于这种情况，我觉得有几种处理方式：
- 用一个概念统一起来。我觉得直接用 TPS 就行了，其他的都在各层面加上限制条件来描
述。比如说，接口调用 1000 Calls/s，这样不会引起混淆。 - 在团队中定义清楚术语的使用层级。
- 如果没有定义使用层级，那只能在说某个概念的时候，加上相应的背景条件。
压力工具中的线程数和用户数与 TPS
下面的一个框有四个箭头，每个都代表相同的事务。
在说这个图之前，我们要先说明”并发“这个概念。他是需要具体的指标来承载的。你可以说，我
的并发是 1000TPS，或者 1000RPS，或者 1000HPS，这都随便去定义。但是在一个具体的项目中，当你说到并发 1000 这样没有单位的词时，一定要让大家都能理解这是什么。
在上面这张示意图中，其实压力工具是 4 个并发线程，由于每个线程都可以在一秒内完成
4 个事务，所以总的 TPS 是 16。千万不能把并发理解成 4 了。
那么用户数怎么来定义呢？用户有了业务含义，不能盲目认为一个系统如果有 1 万个用户在线，那就应该测试 1 万的并发线程。通常，我们会对在线的用户做并发度的分析，在很多业务中，并发度都会低于5%，甚至低于 1%。
拿 5% 来计算，就是 10000 用户 x5%=500(TPS)，注意哦，这里是 TPS，而不是并发线程
数。如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并
发线程)。
通过这样的计算逻辑，我们就可以看出来用户数、线程数和 TPS 之间的关系了
但是！响应时间肯定不会一直都是 100ms 。所以通常情况下，上面的这个比例都不会固定，而是随着并发线程数的增加，会出现趋势上的关系。所以，在性能分析中，关注趋势！
业务模型
业务模型可以有这两种方式得到：
- 根据生产环境的统计信息做业务比例的统计，然后设定到压力工具中。有很多不能在线
上直接做压力测试的系统，都通过这种方式获取业务模型 - 直接在生产环境中做流量复制的方式或压力工具直接对生产环境发起压力的方式做压力
测试。这种方式被称为全链路压测
另外常常也有提到的 2 8 原则：大概的意思就是，如果一天有 1000 万的用户在使用，系统如果开 10 个小时的话，在计算并发用户数的时候，就用 2小时来计算，即 1000 万用户在 2 小时内完成业务。
响应时间如何设置
- 同行业的对比数据。
- 找到使用系统的样本用户（越多越好），对他们做统计，将结果拿出来，就是最有效的响应时间的制定标准。
也听过 2 5 8 和 2 5 1 0 原则，据说是 80 年代英国一家 IT 媒体对音乐缓冲服务做的一次调查。在那个年代，得到的结果是，2 秒客户满意度不错；5 秒满意度就下降了,但还有利润；8 秒时，就没有利润了。于是他们就把这个统计数据公布了出来，这样就出现了 258 principle
小结
- 性能测试概念中：性能指标、性能模型、性能场景、性能监控、性能实施、性能报告。
- 性能场景中：基准场景、容量场景、稳定性场景、异常场景
- 性能指标中：TPS、RT