性能分析5部曲:瓶颈分析与问题定位,如何快速解决瓶颈?

时间:2024-02-22 10:14:20

一、引言

很多做性能测试的同学都问过我这样一个问题:鱼哥(Carl_奕然),你说性能测试的重点是什么?

我的回答很简单:瓶颈分析与问题定位。

在性能项目的整个周期,不管是脚本设计,脚本编写还是脚本执行,都还算简单。

难点在于如何定位瓶颈,分析瓶颈,解决瓶颈。

如果你不会性能分析,脚本设计的再好,脚本编写的再完美,分析不出问题所在,那都是白白浪费时间。

所以,这一讲,我们来学习:如何进行性能分析,学会了性能分析的思路,才能定位问题,分析问题,从而解决问题。

在性能项目中,我总结的性能分析思路,分5个模块,即性能分析5部曲,如下:

1、判断性能瓶颈;

2、线程递增策略;

3、性能衰减过程;

4、拆分响应时间;

5、构建分析决策tree;

接下来,我就对这5部曲进行一一解释。

二、判断性能瓶颈

在整个性能测试阶段,让性能测试工程师最艰难的,就是如何定位性能瓶颈。

如果无法定位到性能瓶颈,那么对开发同学的支持也就有了限制,这无疑即增加了解决问题的时间,又增加了开发工程师的工作量。

这时候,你会说,开发工程师的职责不就是解决性能瓶颈吗,

那要是这样说, 测试工程师的职责,可不仅仅是发现性能瓶颈,还需要定位性能瓶颈,换句话说,也就是协助开发工程师快速定位并解决性能问题。

为什么说在整个性能项目中,最难得就是分析性能瓶颈。

这里,我先上一张图,为了更形象的表现接下来要描述的内容,我把图片做了一点处理:
在这里插入图片描述

通过这张图,我们很直观的知道:这是一个阶梯式增加的压测场景。

但是,根据这个图,你能判断出拐点在哪里吗?

如果无法判断哪里是拐点,那我再上一张ResponseTime(后面简称为RT)图:

在这里插入图片描述

同样,为了让你更直观的查看RT图,, 我同样也对RT图做了优化处理。

结合RT图与TSP图,我们能不能判断拐点在哪里呢?

如果你觉得在3.3s的位置是拐点。我不能否认你说的完全错误,但是,我也不会认同你的观点, 为什么呢?

因为,根据多年的经验,判断的标准是:随着TPS的不断增加,找到那个清晰可见的弧度。

这一点很重要,需要你记住。

我举个例子:如果按照你刚刚的说法,只根据一个拐点来进行判断,想象一下,

假如网络出现突然的抖动,按照你刚刚的判断依据(只根据一个拐点),是不是就不准确了。。

所以,一定是找到那个 清晰可见的 弧度。

我们在回来说上面的TPS图与RT图,根据这两个图,你能得出哪些结论呢?

是不是可以得出这个系统有瓶颈,系统的瓶颈与压力有关系,并且随着压力的增加,涨幅在逐渐减少。

到这里, 需要请你在思考一个问题:瓶颈点是否跟压力的大小有关?

答案:肯定不是跟压力大小有关。

既然不是跟压力大小有关,那么,根据什么有关呢?

其实结合上面的图, 我们可以知道:

①引起系统瓶颈的问题是有规律的;

②TPS是周期性的降低,并且最大的TPS也都差不多是一致的;

所以,即使压力降低,最多只是降低最大的TPS水位,这种情况只是让问题出现的更晚一点,但不会不出现的。

最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!