性能调优的关键指标，你都知道吗？

在业务开发中，在讨论一个服务的性能时，经常会提到一些性能相关的指标，如tps,qps,rt并发线程等。虽然这些指标经常被挂在嘴边，但是每个指标的含义，能比较细致的说出来的，却不多，不信可以尝试回答一下下面的几个问题，没准可以get到新技能

1.到底什么是qps？

2.TPS中的T是什么意思？

3.影响TPS的因素?

4."平响"是怎么计算的？

到底什么是qps

QPS 一开始是用来描述 MySQL 中 SQL 每秒执行数 Query Per Second，所有的 SQL 都被称为 Query，也就是说这里的q是指sql语句。但是在其他场景中，也会经常使用qps。比如，在压测工具中，我们经常使用qps来描述系统的吞吐量；在web服务场景中，使用qps来描述，服务器每秒收到的请求数，这俨然就和tps混在一起了。虽然qps用的很乱，但是在一个团队中，当提到qps的时候，大家都知道说什么，也就没有人就较真q到底是什么了。

TPS中的T是什么意思

TPS的原意是系统每秒处理的事务数也就是 Transaction per second的翻译。说到TPS，就不得不详细说一下这里面的T。
我们都知道 TPS 在不同的行业、不同的业务中定义的粒度都是不同的。所以不管你在哪里用 TPS，一定要有一个前提，就是所有相关的人都要知道你的 T 是如何定义的。但是很多时候T是没有一个统一的定义的，那就意味着，你想怎么定就怎么定。通常情况下，我们会根据场景的目的来定义 TPS 的粒度。如果是接口层性能测试，T 可以直接定义为接口级；如果业务级性能测试，T 可以直接定义为每个业务步骤和完整的业务流。也就说，T的定义也结合业务场景。我们用下面一个示意图来说明一下：

上图的流程大致为：客户端调用服务端接口1。接口1依赖接口2和接口3.

对于上图，如果我们要测试每个接口的TPS的话，那么这里的T就是每个接口，TPS就表示，一秒内，每个接口可以处理的请求次数。

如果我们要测试整个业务的TPS的话，那么接口1,2,3就在一个T中了，那么业务的TPS，就是一秒内，系统可以处理客户端请求的次数。

但是有时候，测试系统的TPS时，还要分析系统的架构设计，比如说，接口1对接口2和3的调用方式是异步的，那么此时整个业务，可以只看成接口1，此时业务的TPS，数值上可能会更高一些，但是对接口2和接口3也需要进行TPS的分析。

在大部分的性能测试中，TPS都是一个非常重要的指标，因为它通常用来描述一个系统吞吐量的大小，当一个系统的TPS比较大时，说明该系统的的吞吐量比较大，对一个系统性能调优的手段可能会有很多，但是最终的目标就是提高系统的TPS。

影响TPS的因素

通过上面的分析，我们知道了TPS对于一个系统的重要性，系统的调优都是奔着提高系统TPS这个目标去的。但是影响TPS的因素又有哪些呢？

通常情况下影响TPS的因素有两个，事务处理时间和系统中事务处理的并发度。

通常来说，事务处理时间描述的是服务端处理一个事务的开始时间，到这个事务处理完毕的结束时间之间的时间间隔。
如下图所示：

如果事务表示的是每个接口，那么M1_T2-M1_T1就是接口1的事务处理时间，M2_T2-M2_T1就是接口2的事务处理时间，M3_T2-M3_T1就是接口3的事务处理时间。

而对于对于用户请求处理的事务来说，事务处理时间就是M1_T2-M1_T1(同步调用的场景下，该时间间隔包含了接口2和接口3的处理时间)。计算方式非常直接简单。但是，我们要知道，这个时间包括了后面一连串的链路。事务处理时间的概念简单至极，但是，对于事务处理时间过长这个问题的定位，就比较复杂了，因为M1_T2-M1_T1这个事务的处理时间，是很多小的事务处理时间组成的。所以要分析一个大事务的处理时间长的问题，就要统计出每个小事务的处理时间，找出响应时间比较长的那个事务，然后对其进行分析。
好在现在有很多链路监控工具和一些 Metrics统计的工具，会记录真个调用链路中，每个方法执行耗时，可以让我们一眼就看出处理时间比较长的事务。

为了提高系统的TPS，我们可以通过技术手段，减少事务的处理时间，提高单位时间内，单个线程处理的事务个数。

除此之外，增加事务处理线程个数，也可以在一定范围内，提高系统的TPS。这里之所以说在一定范围内对TPS进行提供，主要是因为线程个数设置的过大，反而会影响系统的性能，因为线程过多的情况下，cpu的大部分时间都花在线程的上下文切换了，反而增加了每个事务的处理耗时。线程个数在一定范围内的前提下，TPS的计算方式为：
tps=工作线程数*(1000ms/事务处理耗时)。所以影响TPS的因素主要是事务的处理时间和事务的处理线程数。

"平响"是怎么计算的

很多时候大家都会把事务的处理时间和响应时间混在一起。有时候两者在数值上可能是相同的，但是，两者却是两个完全不同概念，两者的差异主要体现在面向的对象不同，响应时间主要面向客户端来说的，而事务处理时间主要面向服务端来说的。

响应时间又称为RT,也就是 response time的缩写。它用来描述一个请求发起时刻到收到响应时刻之间的时间间隔，也就是上面第二张图的T2-T1。

为了更形象的说明两者的差异，我举两个具体的例子：
1.在一个网路延迟比较大的环境中，对于客户端来说，一个请求的响应时间很长，但是服务端对每个请求的处理都很快，处理时间都比较短。

2.假如客户端对请求的响应时间比较敏感，响应时间要限制在50ms内。服务端对请求的处理也比较快，对于每个请求的处理可以控制在1ms内完成，但是如果服务端对请求的处理是串行的情况下，某一时刻有100个请求同时到达服务端，在不考虑网络延迟的情况下，仍会有近50个请求的响应时间大于50ms。

在实际的开发工作中，统计每个请求的响应时间，并没有太大的意义，在分析请求的响应时间时，通常看的是请求的平均响应时间，也就是所谓的"平响"。

平响的计算方法就是所有事务响应时间的平均值。

如果此时有人问你，某个事务的处理时间稳定为t1，那这个请求的平均响应时间是多少，可能大部分人会觉得：每次请求处理都是t1，平均响应时间，就是n*t1/n=t1。如果你也觉得是这样计算的话，那么你就掉坑里了，因为计算系统平均响应时间还要考虑另外一个因素——系统事务处理并发数。

这里我再举个例子：假设某个系统处理某个事务的耗时t1，且这个系统只有一个线程来处理该事务。T时刻，系统收到的3个客户端请求，由于系统是对请求的处理是串行的，那么第一个请求的响应时间为(T+t1-T)=t1，第二个请求的响应时间为(T+t1+t1-T)=2t1，第三个请求的响应时间为(T+t1+t1+t1)-T=3t1。那么此时，对于这个事务的平均响应时间就是(t1+2t1+3t1)/3=2t1，而不是t1。这里平均响应时间是2t1的根本原因就在于：请求到达服务器后，不一定会被立即执行，可能需要等待其他请求的处理，这也是响应时间和处理时间的差异所在。

如果服务器的配置比较高一些的话，我们开启3个线程来同时处理以上的三个请求的话，那么以上3个请求响应时间分别是t1，t1，t1。那么平均响应时间就是(t1+t1+t1)/3=t1。所以响应时间都是大于等于请求的处理执行时间的。

系统的平响和TPS一样，都可以比较系统全面的描述系统的性能。TPS越高系统吞吐量越大，性能越强。而在某个TPS下，平响越低，也可以说明这个系统的性能越强。