性能测试分析

作者：美得冒泡的姗迪

次浏览

次

2022-6-8

编辑推荐:

本文将介绍性能分析的基本概念：QPS/TPS ，希望同样对你有所帮助。
本文来自于简书，由Alice编辑、推荐。

很多人不会做性能分析或者调优的关键点在于：不知道怎么做性能分析。很多人觉得性能调优是一件很难的事情，无从下手。其实这些都有方法，只要掌握了一定的方法和技巧，这不是一件很复杂的事情。

两个最朴实的概念:QPS/TPS

QPS : Query Per Second TPS : Transactions Per Second 这两个概念起源于数据库系统，是衡量数据库性能的重要指标。数据库的操作可以分为增、删、改、查这几类。 QPS用在对于查询类的性能统计，这类查询基本不需要在事务块中进行限制，不用在独立的事务块中保持独立；对于非查询类，通常是需要在事务块中进行数据的ACID保证，所以对事务或者资源具有独占性，性能情况会受制于独占资源的消耗。` 在应用系统中，QPS和TPS的概念经常已经混淆。但是其基本语义未变：可以泛指在特定周期内的处理能力。

影响QPS/TPS的主要因数

先举例几个压测是经常遇到的几个场景

场景1：**线程池和QPS的关系**

某一天一个开发做压力测试。在一台4核机器上测试。先是用10个用户压测,测出QPS为60;

再用20个用户压测,测试QPS 为100;

最后一次用30个用户压测,测试QPS为100,怎么30个用户的QPS 就不增加了呢?

于是他增加了线程池的线程数量由10调整到30,再次使用30个用户进行压测,居然QPS还是200左右。

他索性又把线程池的线程数量增加到50,再次30个用户压测,奇怪了!

怎么QPS还是200左右,没有增加呢!

请问:为什么增加线程池,QPS先是上升,再次增加就不上升了呢?

场景2：**什么是瓶颈资源**

某一天这个开发做压⼒测试。

在一台4核机器上测试。

这次是一个新的业务,此业务中含有数据库事务,对单条记录操作的时候会上锁。

于是他开始测试,用10个用户压测,测试QPS为40左右; 于是他用20个用户压测,居然还是40左右;30个用户,依然如此。

好吧,既然不想,老招数,加⼤大线程池,由10上升到20,再到30依然没有。

绝望了,性能实验室,有台8核机器,来吧,试试。。。。 QPS居然还是40左右。。。

请问:为什么增加线程池,甚⾄至增加CPU核数,QPS没有增加呢?

场景3：**响应时间和QPS的关系**

某⼀天这个开发接到一个任务。

又是烦人的外围配合改造,改造是这样的:某个系统做了性能优化,老的服务调用需要50ms,⽽现在只需要20ms。

这个开发一想,这不是很好嘛,可以减少业务处理时间,那请求的响应时间自然就变少了,那QPS不是就增加了么?

想的倒是很美。。。

于是配合改造,发布上线,到线上一看,XX的,响应时间确实少了,但是怎么QPS没有增加呢?

请问:为什么响应时间变少,QPS没有增加,响应时间和QPS的关系是什么呢?

通过上面的几个场景，没有经验的人可能会比较迷惑。

传统QPS公式可以写成：QPS = 1000ms/响应时间 * CPU核数，这个是多数人的理解：当机器由4核换成8核的时候，QPS一定是会增加的，因为可以用于处理的CPU更多了当响应时间变少的时候，分母变小了，所以QPS增加了。

但是通过上面的例子可以看出，实验结果不是想得这样。

（当然如果你怀疑列举的场景，可以自己做下实验）

那么问题来了：**是什么影响了QPS，QPS和CPU、线程、响应时间、并发量之间的关系是什么？

关系图.png

深入剖析响应时间

多数人不能正确的去分析QPS，绝大部分的原因是不知道响应时间具体消耗在什么资源上，所以做不了正确的分析和判断。所以自己先从响应时间上去解释，下列的响应时间模型是我自己提炼的，未必是完全符合理论或者所有人的理解。 V1版本的响应时间模型：响应时间=请求传输时间+服务端处理时间+响应传输时间这个版本的服务端处理时间很笼统。

V2版本的响应时间模型：

响应时间=请求传输时间+内部服务处理时间+外部服务处理时间+响应传输时间这个版本的服务端服务端处理时间拆分成两部分

V3版本的响应时间模型：响应时间=请求传输时间+服务内部CPU运算+服务内部IO时间+外部服务处理时间+响应传输时间这个版本的服务端服务端处理时间进一步拆分，拆分为不同的资源消耗

V4版本的响应时间模型：响应时间=请求传输时间+服务内部CPU运算+服务内部IO时间+内部共享资源时间+外部服务处理时间+响应传输时间

通过上面的分解，对响应时间有个分解。最后把响应时间的组成提炼为如下内容

理解最优线程数

最优线程数的定义：使用最少的线程保持资源最大化的使用。常有两种情况：当线程数较少的时候,压力情况下,可能造成线程资源不足,请求需要等待线程释放后,才能处理。当线程数量较多的时候,线程自身也是需要消耗内存资源,导致资源的浪费;同时,线程较多的时候对于线程的调度和争用也会影响性能。对于最优线程数常常有一些经验或者理论上的值： N+1:保证CPU在一定的阻塞情况下,也有可以运行的线程进⾏调度,进而保证CPU的运⾏和利用 N-1:减少线程和线程调度间的争用和调度这些理论值常常是没用的！！！

理解响应时间、最优线程数、CPU之间的关系

下面以一个例子来说明这几个的关系：假设一个请求的响应时间是100ms，1个CPU，1个线程的情况下推演。

一个请求的执行快照如上图。处理过程大概为：请求1绑定到线程1，线程1绑定到cpu1，cpu1上执行100ms完成本次请求；线程1继续处理后续请求，比如请求2、请求3。但是通过上面响应时间模型可以得知，一个请求的响应时间不一定全部都是CPU耗时组成，那么可能运行的快照如下图：

当一个请求只有20ms在CPU上运行，其余的80ms都在等待外围的响应，那么可以得出：线程1会在等待外围80ms是阻塞；cpu1会在线程1阻塞时空闲。那么为了让CPU满转，资源使用最大化，那么需要使用几个线程呢？

通过上图可以看出，当有线程阻塞，不断的补充线程进行执行，就可以让CPU满转。大概可以得出：最优线程数=线程总时间/线程CPU执行时间 * CPU核数。似乎分析到这里，应该就快清晰的知道答案了，但是我们离的还远。下面进一步分析

理解瓶颈资源：多资源情况下的线程调度分析

假设这样的一个场景：假设一个请求的服务器端处理时间为10ms。其中cpu执行5ms,4个CPU;数据库操作时间5ms,应用总共有2个可用连接那么最后线程数是多少？如果按照上一步计算：最优线程数=线程总时间/线程CPU执行时间 * CPU核数=10ms/5ms * 4 = 8 上面的计算正确吗？为了解释多资源情况下的线程调度，使用如下几个快照分析。把CPU时间划分为5ms为一个时间段区域 1、第1个5ms快照的运行情况如下：同时有4个线程在4个CPU上运行，cpu处于满转。