前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >LoadRunner教程(15)-LoadRunner 初识Analysis

LoadRunner教程(15)-LoadRunner 初识Analysis

作者头像
全栈程序员站长
发布2022-08-31 19:44:22
6330
发布2022-08-31 19:44:22
举报

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

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轴表示服务器的吞吐量(以字节为单位)。吞吐量直接反映了服务器的处理能力,如果服务器处理的吞吐量的值越大,说明服务器处理业务的能力越强,但是在测试过程中不可能一次就测试出服务器吞吐量的值,必须经过多次测试才能找到吞吐量的值,即测试过程中一定要找到吞吐量的拐点,这样才能找到服务器处理业务时的最大吞吐量,亦即服务器处理的最大能力。

这里写图片描述
这里写图片描述

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

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2022年5月2,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档