一、性能分析思路大纲
- 瓶颈的精准判断;
- 线程递增的策略;
- 性能衰减的过程;
- 响应时间的拆分;
- 构建分析决策树;
- 场景的比对。
二、瓶颈的精准判断
1.TPS 曲线
对性能瓶颈做出判断是性能分析的第一步,有了问题才能分析调优。
之前有很多人在描述性能测试的过程中,说要找到性能测试中曲线上的“拐点”。我也有明确说过,大部分系统其实是没有明确的拐点的。
举例来说,TPS 的视图如下:
显然,这是一个阶梯式增加的场景,非常好。但是拐点在哪呢?有人说,显然在 1200TPS 左右的时候。也有人说了,显然是到 1500TPS 才是拐点呀。但是也有人说,这都已经能到 2000TPS 了,显然 2000TPS 是拐点。
我们再来看一下这张图对应的响应时间视图:
是不是有人要说响应时间为 4.5ms 时是拐点了?
其实这些对拐点的判断,都是不合理的。如果我们对 TPS 的增加控制得更为精准的话,那么这个 TPS 的增加是有一个有清晰的弧度,而不是有一个非常清晰的拐点。
但是至少我们可以有一个非常明确的判断,那就是瓶颈在第二个压力阶梯上已经出现了。因为响应时间增加了,TPS 增加得却没有那么多,到第三个阶梯时,显然增加的 TPS 更少了,响应时间也在不断地增加,所以,性能瓶颈在加剧,越往后就越明显。
那么我们的判断就是:
- 有瓶颈!
- 瓶颈和压力有关。
- 压力呈阶梯,并且增长幅度在衰减。
如果你觉得上面的瓶颈还算清晰的话,那么我们再来看一张图:
在这个 TPS 的曲线中,你还能判断出拐点在哪吗?
显然是判断不出来拐点的,但是我们根据图得出以下几个结论:
- 有瓶颈!
- 瓶颈和压力有关。
- 压力也是阶梯的,但是并没有明确的拐点。
我们再来看一个 TPS 图:
看到这张图,是不是明显感觉系统有瓶颈呢?那么瓶颈是不是和压力大小有关呢?
这种比较有规律的问题,显然不是压力大小的原因。为什么呢?因为 TPS 周期性地出现降低,并且最大的 TPS 也都恢复到了差不多的水位上。所以,即使是压力降低,也最多降低最大的 TPS 水位,会让问题出现得更晚一点,但是不会不出现。
综合以上,如果画一个示意图的话,TPS 的衰减过程大概会如下所示:
- 随着用户数的增加,响应时间也在缓慢增加。
- TPS 前期一直都有增加,但是增加的幅度在变缓,直到变平。
在这样的趋势图中,我们是看不到明确的拐点的。但是我们能做的清晰的判断就是:有瓶颈!
所以对 TPS 曲线来说,它可以明确告诉我们的就是:
- 有没有瓶颈:其实准确说所有的系统都有性能瓶颈,只看我们在哪个量级在做性能测试了。
- 瓶颈和压力有没有关系:TPS 随着压力的变化而变化,那就是有关系。不管压力增不增加,TPS 都会出现曲线趋势问题,那就是无关。
这时你可能会问,为什么不看响应时间就武断地下此结论呢?其实响应时间是用来判断业务有多快的,而 TPS 才是用来判断容量有多大的。
2.响应时间的曲线
我们还是来看看响应时间,下面看一张响应时间图:
它对应的线程图是:
多明显的问题,随着线程的增多,响应时间也在增加,是吧。再来看它们对应的 TPS 图:
到第 40 个线程时,TPS 基本上达到上限,为 2500 左右。响应时间随着线程数的增加而增加了,系统的瓶颈显而易见地出现了。
但是,如果只让你看 TPS 曲线,你是不是也会有同样的判断?那就是:有瓶