一.性能测试分析的能力阶梯视图
二.性能分析思路大纲
- 瓶颈的精准判断
- 线程递增的策略
- 性能衰减的过程
- 响应时间的拆分
- 构建分析决策树
- 场景的比对
1.瓶颈的精准判断
-
响应时间是用来判断业务有多快的,而 TPS 才是用来判断容量有多大的。
-
TPS曲线
-
TPS衰减图:
- 随着用户数的增加,响应时间也在缓慢增加。
- TPS 前期一直都有增加,但是增加的幅度在变缓,直到变平。
-
TPS曲线可以告诉我们:
- 有没有瓶颈:其实准确说所有的系统都有性能瓶颈,只看我们在哪个量级在做性能测试了。
- 瓶颈和压力有没有关系:TPS 随着压力的变化而变化,那就是有关系。不管压力增不增加,TPS 都会出现曲线趋势问题,那就是无关。
-
-
响应时间
-
响应时间图
-
对应线程图
-
对应TPS图
- 通过上图三个图我们可以看出,到第40个线程时,TPS基本上达到上限,为2500左右,响应时间随着线程数的增加而增加了,系统的瓶颈也出现了。
-
2.线程递增的策略
- 对一个系统来说,如果仅在改变压力策略(其他的条件比如环境、数据、软硬件配置等都不变)的情况下,系统的最大 TPS 上限是固定的。
- 对于场景中线程(有些工具中叫虚拟用户)递增的策略,我们要做到以下几点:
- 场景中的线程递增一定是连续的,并且在递增的过程中也是有梯度的。
- 场景中的线程递增一定要和 TPS 的递增有比例关系,而不是突然达到最上限。
- 对于秒杀类的场景,我们前期一定是做好了系统预热的工作的,在预热之后,线程突增产生的压力,也是在可处理范围的。这时,我们可以设计线程突增的场景来看系统瞬间的处理能力。如果不能模拟出秒杀的陡增,就是不合理的场景。
3.性能衰减的过程
-
压力产生结果图
-
通过计算可以得到统计图
- 通过对比知道, 当每线程每秒的请求数降到 55 左右的时候,TPS 就达到上限了,大概在 5000 左右,再接着往上增加线程已经没有用了,响应时间开始往上增加了。这就是性能衰减的过程(在上图中,在红线前面,性能在上升的过程中有几次抖动,这个抖动到后面变大了,也变频繁了,如果这是必然出现的抖动,那也是配置问题。)。
- 通过上述栗子可以得出: 只要每线程每秒的 TPS 开始变少,就意味着性能瓶颈已经出现了。但是瓶颈出现之后,并不是说服务器的处理能力(这里我们用 TPS 来描述)会下降,应该说 TPS 仍然会上升,在性能不断衰减的过程中,TPS 就会达到上限。
4.响应时间拆分
- 响应时间通常是一个分析的起点, 在压力工具上看到的响应时间,都是经过了后端的每一个系统的。那么,当响应时间变长,我们就要知道,它在哪个阶段时间变长了。
- 比如架构如图所示,拆分时间应该是比较清楚的:
5.构建分析决策树
-
分析决策树, 是对架构的梳理,是对系统的梳理,是对问题的梳理,是对查找证据链过程的梳理,是对分析思路的梳理。它起的是纵观全局,高屋建瓴的指导作用。
-
分析决策图
- 从压力工具中,只需要知道 TPS、响应时间和错误率三条曲线,就可以明确判断瓶颈是否存在。再通过分段分层策略,结合监控平台、日志平台,或者其他的实时分析平台,知道架构中的哪个环节有问题,然后再根据更细化的架构图一一拆解下去。
-
数据库分析决策树,对 RDBMS 中的 MySQL,可以画一个如下的决策树
-
操作系统分析决策树
6.场景的对比
- 当你觉得系统中哪个环节不行的时候, 又没能力分析它,你可以直接做该环节的增加。