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

Response Time。可以简单理解为：网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间 从一个实例中理解： RT = T2 - T1 。计算方式似乎容易，但是响应时间的定位就比较复杂了。因为性能测试工具都会记录响应时间，但是，都不会给出后端链路到底哪里慢。 从这个简单架构图来看请求链路： 在所有服务的进出口都做记录，然后计算结果，在网关、总线这样的系统都会考虑这个功能。现在的一些链路监控工具和一些 Metrics 的使用可以完成需求，他会记录每一个请求链路上每个节点消耗时间和请求的持续时间。

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 之所以重要，是因为它可以反应出一个系统的处理能力。

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

Request per second，每秒请求数。对于请求数来说，要看是在哪个层面看到的请求，因为请求这个词，实在是太泛了。我们把上面的图做一点点变化来描述一下请求数 如果一个用户点击了一次，发出来 3 个 HTTP Request，调用了 2 次订单服务，调用了 2 次库存服务，调用了 1 次积分服务，那么这个 Request 该如何计算？

在具体的项目中，我们会单独描述每个服务，以便做性能统计。如果要描述整体，最多算是有 3 个 RPS。如果从 HTTP 协议的角度去理解，那么 HTTP Request 算是一个比较准确的描述了，但它本身的定义并没有包含业务。如果赋予它业务的含义，那么用它来描述性能也是可以的

吞吐量是指系统在单位时间内处理请求的数量，用于衡量网络性能或软件性能,TPS、QPS都是吞吐量的常用量化指标。

一个系统的吞吐量（承压能力）与request（请求）对cpu的消耗，外部接口，IO等等紧密关联。 单个request 对cpu消耗越高，外部系统接口，IO影响速度越慢，系统吞吐能力越低，反之越高。

Hits Per Second，每秒点击数。Hit 一般在性能测试中，都用来描述 HTTP Request。但是，也有一些人用它描述真正的客户在界面上的点击次数。关于这一点，就只有在具体的项目中才能规定得具体一些。当它描述 HTTP Request 时，如果 RPS 也在描述HTTP Request，那这两个概念就完全一样了

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

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

下面的一个框有四个箭头，每个都代表相同的事务。 在说这个图之前，我们要先说明”并发“这个概念。他是需要具体的指标来承载的。你可以说，我 的并发是 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