LoadRunner教程(15)-LoadRunner 初识Analysis

LoadRunner教程(15)-LoadRunner 初识Analysisanalysis简介分析器就是对测试结果数据进行分析的组件,它是LR三大组件之一,保存着大量用来分析性能测试结果的数据图,但并不一定要对每个视图进行分析,可以根据实际情况选择相关的数据视图进行分析,分析结果可以生成一些不同格式的测试报告,可以对不同的图表进行合并分析。在controller里面点击analysis,可以生成分析图表或者在开始运行场景时…

大家好,又见面了,我是你们的朋友全栈君。

analysis简介
分析器就是对测试结果数据进行分析的组件,它是LR三大组件之一,保存着大量用来分析性能测试结果的数据图,但并不一定要对每个视图进行分析,可以根据实际情况选择相关的数据视图进行分析,分析结果可以生成一些不同格式的测试报告,可以对不同的图表进行合并分析。
在controller里面点击analysis,可以生成分析图表
这里写图片描述
或者在开始运行场景时保存运行脚本的路径
这里写图片描述
然后打开analysis,选择之前保存的运行脚本
这里写图片描述
这里写图片描述
点击生成分析如下
这里写图片描述
analysis会话窗口
这里写图片描述
这里写图片描述

摘要报告
这里写图片描述
一、概要部分
这里写图片描述
二、统计部分
这里写图片描述
三、事务统计部分
这里写图片描述
第一行统计场景运行时所有事务通过、失败、停止的数量。而表格里则是显示了所有事务执行时的详细信息:

1)transaction name(事务名);2)minimum(事务运行的最短时间);3)average(事务运行的平均时间);4)maximum(事务运行的最长时间);

5)std.deviation(标准方差):方差描述一组数据偏离其平均值的情况,方差值越大,说明这组数据就越离散,波动性也就越强;反之,则说明这组数据就越聚合,波动性也就越小;

6)90 percent:在controller运行场景时,并不会显示这个值,因为它是对整个一系列数据统计的结果。表示一个事务在执行过程中的90%所花费的时间,比如,一个事务执行了100次,对这100次事务响应时间进行升序排序,第90%即90次事务运行时间;

7)pass(通过的事务个数);8)fail(失败的事务个数);9)stop(停止的事务个数):在执行场景时,若用户手工停止场景的执行,事务没有自己的状态,那么就是停止状态。

注:事务的通过率一定要大于95%,也即失败率应该小于5%,因为如果事务失败率过高,就说明客户在使用系统时很容易出现错误,这样无论事务响应时间多么短也是不符合要求的,因为客户最基本的需求都没有被满足,功能都不能正确的处理,那么更无法谈性能了。

analysis常见图分析
这里写图片描述
在LR分析器中对资源使用的情况分析得很少,因为通常在性能测试过程中很少使用LR来监控系统资源的使用,特别是UNIX、LINUX和ALX操作系统,几乎不使用LR来监控,更多的是借助第三方工具来监控,当然如果服务器是windows操作系统,那么使用LR进行监控比较简单。
一、vuser图
它显示vuser状态和完成脚本的vuser的数量。将这些图与事务图结合使用可以确定vuser的数量对事务响应时间产生的影响。X轴表示从方案开始运行以来已用的时间,Y轴表示方案中的vuser数,vuser图显示在测试期间的每一秒内执行vuser脚本的vuser数量及其状态。可以帮助确定任何给定环境中服务器上的vuser负载。默认情况下,此图仅显示为running的vuser。
这里写图片描述
二、点击率图
显示在方案运行过程中vuser每秒钟向web服务器提交的HTTP请求数。借助此图可以依据点击次数来评估vuser产生和负载量。一般会将此图与平均事务响应时间图放在一起进行查看,观察点击数对事务性能产生的影响。X轴表示方案从开始运行以来所用的时间,Y轴表示服务器上的点击数。
注意:点击率并不能衡量服务器的真实处理能力,也不能仅仅通过点击率来衡量服务器的处理能力,因为服务器即使出现 了瓶颈也还会影响到这个值的变化,因为LR其实也是一个代理录制的工具,将录制过程中提交的请求录制成脚本,在回放时模拟用户重新提交这些请求,那么在提交的时间LR可以对HTTP请求进行统计,进而生成点击率视图。但是这并不代表LR画出来的点击率视图一定正确,假如客户端实际提交的HTTP请求为2000个/s,但点击率视图画出来的值为1000个/s,这说明客户端提交的请求根本就没有完全发送到服务器,那么这种情况最有可能是在网关处请求出现超时,因为每个网关端口都有一个允许其访问的最大值,当这个值过大时,网关也会出现排队现象,如果队列过长就会导致一些请求出现超时现象,最后导致统计出来的点击率的值不正确。
这里写图片描述
三、平均事务响应时间图
显示方案在运行期间执行事务所用的平均时间。X轴表示从方案开始运行以来已用的时间,Y轴表示执行每个事务所用的平均时间(s)。平均事务响应时间最直接地反映了事务的性能情况,一般会将平均事务响应时间图与vuser图对照着看,来观察vuser运行对事务性能的影响。可以右键选择show transaction breakdown tree查看子事务或者所有的事务每个页面所花费的时间。
平均事务响应时间图直接反映系统的性能情况,这也是客户眼中的性能,在需要时必须明确地定义好业务的响应时间,在分析时一般先分析的响应时间,当平均事务响应时间符合定义时,也仅仅说明响应时间能达到要求,但是此时并不代表系统达到客户要求,因为LR统计出来的事务响应时间不一定正确,所以当事务响应时间达到要求后,也一定要分析一些其他的数据,需要确定的是业务是否都做成功了,如果业务都做成功了,并且事务响应时间达到要求,这样才能说明事务响应时间达到客户的要求;如果平均事务响应时间达不到要求,就需要进一步分析,是哪些原因导致事务响应时间过长,这样才能进一步优化系统的性能。
这里写图片描述
四、吞吐量图
显示方案运行过程中服务器上每秒的吞吐量。吞吐量的单位为字节,表示 vuser在一秒时间内从服务器获得的数据量。借助此图可以依据服务器吞吐量来评估vuser产生的负载量,可以和平均事务各应时间图对照观察,以查看吞吐量对事务性能产生的影响。
X轴表示 方案从开始运行以来已用的时间,Y轴表示服务器的吞吐量(以字节为单位)。吞吐量直接反映了服务器的处理能力,如果服务器处理的吞吐量的值越大,说明服务器处理业务的能力越强,但是在测试过程中不可能一次就测试出服务器吞吐量的值,必须经过多次测试才能找到吞吐量的值,即测试过程中一定要找到吞吐量的拐点,这样才能找到服务器处理业务时的最大吞吐量,亦即服务器处理的最大能力。
这里写图片描述

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/142351.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号