（五）性能分析思路

一.性能测试分析的能力阶梯视图

二.性能分析思路大纲

• 瓶颈的精准判断
• 线程递增的策略
• 性能衰减的过程
• 响应时间的拆分
• 构建分析决策树
• 场景的比对

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.场景的对比

• 当你觉得系统中哪个环节不行的时候， 又没能力分析它，你可以直接做该环节的增加。