性能分析之趋势分析

前言

这会想聊一下性能分析中的趋势分析。

遇到问题

我看过很多的性能报告，像这样的表格有很多。（下面这个是平均响应时间的表格）

然后画了一个 TPS 的图是这样：

系统资源呢，也是像这样来个表格。

然后呢，再画一个图（假设这是 CPU 的图）

看到这里，我觉得应该：

• 有些人心里想，嗯，这图挺好，明明白白的。
• 也有人心里想，嗯，我就是这么干的。
• 也有人心里想，嗯，是呀就应该是这样呀，没毛病。
• 也有人心里想，哦。

我要说，不建议性能报告这么写。为啥呢？

我们先来说说这样写的必要性。

因为有些人做性能场景的时候，是把 ramp up 和ramp down这两部分的数据给截掉的。我之前问过别人为什么一定要抓稳定的TPS 和响应时间曲线？为什么问这个问题呢？得到过一个回答：领导要看稳定的曲线，好汇报！

为什么领导要看稳定的曲线，就要千方百计弄个稳定的、合领导心理的、稳定的曲线呢？（因为领导不高兴，就不给钱！那我只能说，没毛病！）

这曲线是否反应真实的性能状态呢？

还有一些人是因为看到别人这样写，所以他们也这样写，然而并没有什么反省。

那这样写有什么问题呢？

嗯，其实没啥问题，我也就是问问。（不知道有没有人觉得很无奈看到这里？）

如何正确的做？

我觉得这个曲线要是说反应 TPS 和系统资源的关系。这样说，似乎是没毛病的。所以经常看到下面的描述会是这样的：

总 TPS 在达到 4581 的时候，服务器 7 的 CPU 使用率达到了 92.25、服务器 8 的 CPU 使用率达到了 89.92。

上面这句也就是结果分析中的了。

这样的结果分析有什么用呢？曲线中认真一点的就已经看出来了。为什么还要描述一遍图中的数据又称之为结果分析呢？

我觉得这样的结果分析就是耍流氓。因为没有在分析，而只是在描述数据。做为广而告之的话，我觉得这样写也没什么不可以。但是做为结论分析的话，就不合理了。

那说了半天，你觉得什么才是合理的结果分析的话呢？

我觉得在描述 TPS、RT、OS 资源使用率等信息时，应该用实际的图。

比如说：我们有一个java写的应用，为了便于引导思路，这里的结构图非常简单。

就是： 压力工具 <-> 应用服务器 <-> DB服务器

TPS 图是这样的：

响应时间图是这样的：

应用服务器 CPU 图是这样的：

应用服务器 IO 是这样的：

应用服务器 GC 状态是这样的：

应用服务器网络是这样的：

DB CPU是这样的（其他资源不帖了，我帖累了，默认其他的都没问题吧）：

上面的信息我觉得帖得够了。基本上有经验做性能分析的人，看到上面的图就知道一个明确的信息：这个系统有瓶颈。

为什么？因为趋势！！

所以，性能分析要趋势分析，要看的是很多数据组成的曲线。而不是每个梯度找个平均值来描述下值就是结果分析了。

另外一个不能用均值描述的原因是，有很多测试，在资源的分配、增减的时候会出现响应时间和另外一些资源的毛刺。

毛刺也是需要解释的。比如说我发的 TPS 图中就出现了 00:10:00 的时候，tps 有下降的情况，并且后面还持续了一会。在这时候也看到了有响应时间的增加。

为什么会出现这种情况呢？这个也是要在分析中解释的。在我这个图中是因为数据库主机中有其他的任务导致了这一段的 sql 执行时间普遍增加了几个毫秒。

图中的曲线的解释是需要层层分析，慢慢细化，这个过程就是来描述上线后的情形。如果出现了某个用户的响应时间比较长，也是在意料之中的。

结果分析是要描述单个曲线的同时，比如说，上图中的 TPS 是有按梯度增加的，也有没增加的，这就是场景的设计了。再结合响应时间图，有几个业务在随着 TPS 的增加而增加，增加的梯度和方差也都从结果中可以看到。 从 TPS、RT 上，可以把场景的设计明显的看出来。

然后再从 TPS、RT、资源图上，可以明显知道性能瓶颈是不是有的。但是这并不是说，瓶颈是可以从图上反应出来，那还是不行的。

我现在在做项目中都会明确地说：

• 如果硬件资源用不上去，那就先用硬件资源；
• 硬件资源用上去了，目标没达到，那就开始调优。
• 如果资源没用上去，TPS 也不增加，响应时间又增加了，那必须得找到问题在哪。
• 在性能结果分析中也要描述当前的状态是什么，合理不合理。
• 还要描述性能瓶颈在什么地方。给出上线维护的建议。

总结

性能分析首先是全局趋势分析，然后层层细化的过程。

如果只是为了报告的报告，那就另当别论了。