性能测试爬坑之路17 Analysis--结果分析工具三

关住 公 纵 号 “  阿蒙课程分享    ”  获得学习资料及趣味分享　

我们这次主要关注：图表右键功能

我们随便挑一个图表看看右键，我们挑几个比较重要的菜单选型做分析和演示

就拿这个响应时间来说好了  Average Transaction Response Time

右键之后会有很多的选项，看第一个  Set Filter / Group by   (设置一个过滤查询条件，或者对我们的数据进行分组)

点进去 上边部分就是  设置过滤条件  下边部分就是分组

设置过滤条件：因为绘制图表的数据本身也是存储在 Access 数据库中，所以这里跟操作 mysql 数据库的道理一致

比如我们要不要加上思考时间

比如 我们要展示的事务是全部 pass  的还是也包含  fail 和  stopped 的这些响应时间都展现出来?

或者看这里 user_id 好了 ，我们这里的 事务响应时间是针对所有用户而言的，我现在就不妨，查看某几个虚拟用户的响应时间怎么样

这个时候我们看到的我们的数据和平均值核算出来就不是所有的用户的了，而是我挑选的那几个虚拟用户，他们的数据，就是这么一个道理，这是关于过滤条件的，

我们再看下分组，我们这里的 group by  跟数据库中数据分组是一样的道理，

事务的结束状态可以进行分组

VuerID 可以进行分组

我们简单来看一看 事务按照结束状态分组，我们会看到这样的图

如果我们按照用户ID 分组，我们有30个虚拟用户，我们就会看到 30个分组

数据量就很多了，因为每一个事务都有 30 个组，这个数据有什么意义？没有太大的意义，只是让我们对数据有更细致的报表呈现而已，对我们分析来说没有太大的参考价值

这个 drill down 没有什么太多实际的意义，就是把某个事务单领出来显示

【set granularity】 设置一个事务的时间粒度，默认是 8 s,意思是图表中数据点的间隔是 8 秒钟，这边我给大家提醒一下，这个数据点是 4 秒的时间段内取的平均值，当我们设置成 1 秒，我们会看到变成了很多数据点，因为原始数据有很多数据点，默认设置成 4 秒 是因为这样图标显示的好看一点，显的没有那么的拥挤，他的趋势也是可以展现出来的，也可以分析，如果设置成 20 秒，趋势就不容易观察了，建议大家保持 loadrunner 的默认值  4 秒 或者 8 秒，趋势也有了，数据也不会丢失特别严重

【View Measurement Trends】查看趋势，之后的图做了一个稍微的变换，变换后会把几个事务都叠加在一起，方便分析统一分析趋势，这是通过趋势图的重叠我们可以看到的，

变换前

变换后

查看原始数据，默认 选中我们运行的时间段

右边栏有【raw data】我们就已经看到 原始数据了，在这里他会把每一个虚拟用户，发送的每一次请求，都会展示在这里，那个用户 在什么时间发了请求，响应时间是多少（包含思考时间）

我们可以把原始数据直接导出到电子表格里面，导出来之后我们就可以利用 excel 表格的绘图的功能对响应时间这一列画一个折线图，或者直接用 Access  打开 mdb 格式的文件即可，

【重点 start】

【merge graphs】合并图

合并图是什么意思？

    其实前面我们给大家讲了，单纯的一张 Vuser 单纯的一张 HPS 意义也不是很大，单纯的响应时间放在这里我们也只能看到他的平均响应时间的情况，但是他到底对这个系统影响有多大，响应时间的快慢到底跟那个因素的关联性最高，我们其实不清楚，所以我们通过合并图和自动关联的方式，去发掘他们这些数据之间的关联关系，和他们的变化趋势相互之间的影响，这对我们性能测试对瓶颈分析的时候有非常大的帮助，现在我们合并一下看看，我们合并一下虚拟用户数，和平均响应时间，他们之间的一个关联关系到底是怎么样的

    所以我们选择 Vuer 图表  然后右键 选择【merge graphs】

注意如果我们在  average response time 选择合并  vuser 那么因果关系就颠倒了，结果就是随着相应时间的变化 虚拟用户变化趋势，这很明显是倒过来的，因为响应时间是结果，虚拟用户数增加是原因，在 “因” 的图上合并，被合并的图是“果”，

这样这个合并图才会正确的展示他们的趋势，我们跟平均响应时间进行合并，合并类型有三种：

    1.重叠 （就是一前一后重叠在一起看看他们之间的对应关系）

    2. Tile  就是一张表在上面，一张表在下面，两张表对比着来看，这种没有特别的意义，所以不专门去讲（忽略）

    3. correlate  关联：统计学中概念，就是关联性分析的关联（最重要）

你看我的响应时间是不是由略微增加的趋势，虚拟用户数越大相应用户数越长，后边虚拟用户数持平了以后我的响应时间反而也挺频繁的，没有明显的保持一个很平均的状态，左右上下跳动的幅度还挺大，这能得出什么结论吗？通过这张图我们是很难得出这样一个结论的，这个趋势是太不明显了，虚拟用户增加的趋势导致相应时间增加的趋势不明显，不是严格意义上按照这个虚拟用户的增加响应时间慢慢增加的，怎么来解决这个问题？

那我们再来看看 跟 windows resource 合并，看看能不能分析出点什么，把其他的线条隐藏起来，线条太多了，会影响我们的一个判断，

下图是源课程截图

这个图还是挺靠谱的，虚拟用户数在增加，CPU 也在增加，我们虚拟用户数持平了，CPU 也持平了，但是为啥持平？CPU 到 100% ，那最大也就 100% 只能持平了，但是在持平的那一段，还时不时 cpu 会低那么一点，什么原因？CPU 跟虚拟用户数，关联性很高，相关性很强，统计学术语，两条曲线，相关系数是很大的，但是我们看 30 个虚拟用户也到这个系统的极限了，

标准的应该是三层架构，客户端，数据库，服务器

我们再来看相关性的图合并

我们看一下，我们合并之后，横坐标不是时间了，而是虚拟用户数量，纵坐标是响应时间，这张图就变成了随着我们虚拟用户的增加，相应时间的变化趋势，这就是这张图表明的意义，以后我们会看到别的人的一些图，咱们一定要知道这张图代表什么意思，这张图在说什么，这张图就是随着虚拟用户数的增加，响应时间的变化情况，我们可以看到随着用户数的增加，响应时间在慢慢增加，但是跳跃有点大，这就是图表的相关性分析，把一个图变成因，把一个图变成果，这就是图合并的 correlate

这种 correlate 跟我们的 auto correlate 其实是一样的道理，我们再用 auto correlate  来进行分析一下，平均响应时间，

这里的红绿是选择时间段的标记，默认选择全时间段，

这里我想对什么图标进行关联，就对什么图标进行关联，只要勾上即可，这样又会自动生成一张自动关联出来的图片，

这里我们会看到下表中多了一列，叫做【correlation match】关联匹配度，他自己的匹配度是100 匹配度越高，他们之间相互的影响越大，

这里匹配度最高的是 可用的内存数，

但是这里纯粹从统计学角度分析，他们是有问题的，因为他们是成反比的，虚拟用户数是慢慢增加的，可用内存数是慢慢降低的，他们这两者是完全相反的逻辑关系，完全是成反比的，一点关联关系都没有，但为什么关联匹配度最高？但是我们要理解这个指标代表着什么？可用的内存数，可用的内存数在慢慢下降，消耗的内存数在慢慢上升，而我们评估的内存数是消耗的内存数，而消耗的内存数是慢慢的上升过程，他们的匹配度就很高了，

第二个就好理解了，虚拟用户数增加，他的响应时间有点慢慢的增加，但是我们数据颗粒度太大了，数据的采样也不多，所以这个也不够精确，这就是关联分析，它可以帮助我们找到匹配度最高的数据，找到匹配度最高的数据可以用来做什么，相当于我们得出这样一个结论，我们这几个指标受虚拟用户增长的影响最大，虚拟用户数越少，响应时间越快，虚拟用户数越多，响应时间越慢，就是得出这样一个结论，包括我们处理器的长度，也是这样的，虚拟用户数越多，处理器长度就越多

    但是，我们看到我们合并出来的图，太乱了，趋势不够明显，怎么解决这个问题，事实上，我们的脚本本身做的比较凌乱，刚开始的时候，生成的数据没有多么严谨，

潦草的收集一下，到后面我们分析的时候一看就很难受了，一点规律都没有，跳来跳去的，怎么解决，其实最重要最核心的我们在 controller 设置里面，设计场景的时候坚持两个基本的原则，这样，这些变化趋势就准确很多了，这个原则主要是针对 ramp up /down 来说的，

    1. 越慢越好

     2. 平衡好运行时间

就是用户增加越慢越好，这个太快了，每 15 秒增加 5 个，30 个用户很快就加完了，1 分钟就加完了，我们下载把它变慢，每三十秒加 2  个用户，

现在是不是变慢了，加这 30  个用户要十几分钟，慢有什么好处？本身加载用户就需要十几分钟，周期越来越长，用户增加的频率很细很细，这样他获得两者的趋势就很精准，因为很慢，他慢慢的收集这些数据，而且是两个两个的往上涨，他的变化不会这么明显一会五个增加，一会五个增加，他会跳跃太大，你要是有时间一个一个增加都可以，2 个 1 个 这个没有明确的要求，但是不能太慢，我三十个用户可以一个一个来玩，我十几分钟就搞定了，但是我们300个用户呢？一个一个增加我要花两个多小时才能完成 ramp up 的过程，这个太浪费时间了，所以我们有第二个原则，我们要平衡好运行时间，运行时间不能太长了，这还只有 300 个，如果有 3000 个，还不低运行 20 多个小时，所以这个很夸张，这个没有必要，因为我们做的不是长时间的稳定性测试，所以我们要，如果是 3000 个 我们要每 30  秒增加 50  个用户，我们大约花了 20 多分钟，这样还算可以接受，但是这也算是足够慢了，只有这样慢的过程才会让我们收集的数据足够多，趋势体现的足够细

【auto correlate】自动关联