性能测试学习笔记(三)

1.性能测试学习指导

1.1 性能测试阶段

1. 工具操作：包括压力工具、监控工具、剖析工具、调试工具。
2. 数值理解：包括上面工具中所有输出的数据。
3. 趋势分析、相关性分析、证据链分析：就是理解了工具产生的数值之后，还要把它们的 逻辑关系想明白。这才是性能测试分析中最重要的一环。
4. 最后才是调优：有了第 3 步之后，调优的方案策略就有很多种了，具体选择取决于调优成本和产生的效果。

 

1.2 性能测试分析思路

一、瓶颈的精准判断(TPS曲线)

对性能瓶颈做出判断是性能分析的第一步，有了问题才能分析调优。有很多人在描述性能测试的过程中，说要找到性能测试中曲线上的“拐点”。其实大部分系统是没有明确的拐点的。看下图：

通过上图也可以分析出来，有性能瓶颈，瓶颈和压力有关，压力呈阶梯，并且增长幅度在衰减。具体就是瓶颈在第二个压力阶梯上已经出现了。因为响应时间增加了，TPS增加得却没有那么多，到第三个阶梯时，显然增加的 TPS 更少了，响应时间也在不断地增加，所以，性能瓶颈在加剧，越往后就越明显。 

 

这种比较有规律的问题，不是压力大小的原因。为什么呢？因为 TPS 周期性地出现降低，并且最大的 TPS 也都恢复到了差不多的水位上。所以，即使是压力降低，也最多降低最大的 TPS 水位，会让问题出现得更晚一点，但是不会不出现。

 TPS 的衰减过程大概会如下图所示：

1. 随着用户数的增加，响应时间也在缓慢增加。 2. TPS 前期一直都有增加，但是增加的幅度在变缓，直到变平。在这样的趋势图中，我们是看不到明确的拐点的。但是我们能做的清晰的判断就是：有瓶颈！

 所以对 TPS 曲线来说，它可以明确告诉我们的就是：

1. 有没有瓶颈：其实准确说所有的系统都有性能瓶颈，就看是在哪个量级在做性能测试了。
2. 瓶颈和压力有没有关系：TPS 随着压力的变化而变化，那就是有关系。不管压力增不增加，TPS都会出现曲线趋势问题，那就是无关。

二、线程递增的策略

对一个系统来说，如果仅在改变压力策略（其他的条件比如环境、数据、软硬件配置等都不变）的情况下，系统的最大 TPS 上限是固定的。

场景中线程（有些工具中叫虚拟用户）递增的策略，要做到以下几点：

1. 场景中的线程递增一定是连续的，并且在递增的过程中也是有梯度的
2. 场景中的线程递增一定要和 TPS 的递增有比例关系，而不是突然达到最上限。
3. 上面两点针对的是常规的性能场景。对于秒杀类的场景，前期一定是做好了系统预热的工作的，在预热之后，线程突增产生的压力，也是在可处理范围的。这时可以设计线程突增的场景来看系统瞬间的处理能力。如果不能模拟出秒杀的陡增，就是不合理的场景。

性能场景递增参考值：

响应时间	递增幅度
0-50ms	1
50-100ms	1-3
100-200ms	3-5
200-500ms	5-10

三、性能衰减的过程

只要每线程每秒的TPS开始变少，就意味着性能瓶颈已经出现了。但是瓶颈出现之后，并不是说服务器的处理能力（这里我们用TPS来描述）会下降，应该说TPS仍然会上升，在性能不断衰减的过程中，TPS就会达到上限。

这就是性能瓶颈其实在最大TPS之前早就已经出现了。那么是不是应该在性能衰减到最大TPS时就停止场景呢？这个不一定的。因为停不停场景，取决于我们的场景目标，如果我们只是为了得到最大TPS，那确实可以停止场景了。但是，如果我们要扩大化性能瓶颈，也就是说为了让瓶颈更为明显，就完全不需要停止场景，只要不报错，就接着往上压。

四、响应时间拆分

在性能场景中，不管是什么原因，只要系统达到了瓶颈，再接着增加压力，肯定会导致响应时间的上升，直到超时为止。响应时间的分析要具体到系统每一个工具组件甚至每一个模块上，可以使用一些链路监控工具辅助去分析，或者通过查看日志时间的方式进行辅助分析。

五、构建分析决策树

分析决策树，对性能测试分析人员实在是太重要了，是性能分析中不可或缺的一环。它是对架构的梳理，是对系统的梳理，是对问题的梳理，是对查找证据链过程的梳理，是对分析思路的梳理。它起的是纵观全局，高屋建瓴的指导作用。

 从压力工具中，只需要知道 TPS、响应时间和错误率三条曲线，就可以明确判断瓶颈是否 存在。再通过分段分层策略，结合监控平台、日志平台，或者其他的实时分析平台，知道架构中的哪个环节有问题，然后再根据更细化的架构图一一拆解下去。