zoukankan      html  css  js  c++  java
  • LoadRunner 11 中Analysis分析

    原文:http://www.cnblogs.com/Chilam007/p/6445165.html

    analysis简介               

        分析器就是对测试结果数据进行分析的组件,它是LR三大组件之一,保存着大量用来分析性能测试结果的数据图,但并不一定要对每个视图进行分析,可以根据实际情况选择相关的数据视图进行分析,分析结果可以生成一些不同格式的测试报告。

    一、设置选项

        analysis中的数据是怎么得到的呢?其实在场景运行的时候,默认情况下,所有的vuser信息都保存在该vusr的负载机上。只有当场景运行结束后,这些数据才会自动进行整理或合并,这时负载机上所有vuser的信息和数据都将被传输到结果目录中。默认情况下,在controller控制器中,results->auto collate results是被选中的,也就是说默认情况下,当场景运行结束后,这些数据会被自动整理或合并。但当没有选中这项时,场景运行结束后,可以在controller控制器中选择results->collate results 进行手动整理。

        在进行数据视图分析前,有必要将分析图中涉及的一些选项加以设置,过滤掉不需要的数据,方便对数据进行分析。

        下面介绍一些常用的设置选项:

        1、结果目录设置

        在controller控制器中选择results->results setting,如图1所示:

    a.每执行一次场景都生成一份结果文件,结果文件的命名方式为res后接一个序号(如res0),每执行一次序号依次加1;

    b.每执行一次场景,将执行后的结果覆盖以前的结果。(为了防止意外发生,一般会选择第一种结果保存方式)。

    图1(结果目录设置)

        2、result collection设置

        在LR处理这些数据时,可以查看这些数据的摘要,具体怎样查看摘要数据,需要在result collection选项中进行设置,如图2所示:

    图2

        data source:

    a.表示仅查看摘要数据。如果选中该选项,那么analysis还会处理数据以用于筛选和分组等高级用途。且data aggregation项是不可以设置的。

    b.表示仅查看经过处理的完整数据,但是不显示摘要数据。

    c.表示在处理完整数据时,查看摘要数据。

        data aggregation:

    a.表示使用内置数据聚合公式聚合数据,以优化性能

    b.表示使用内置数据聚合公式仅仅聚合与web相关的数据

    c.表示用户自定义来设置聚合数据,如图3所示:

    aggregate data (available only for complete data):用于设置聚合数据的类型,这里只适用于完整数据,可以选择需要聚合数据的图的类型,这样可以减小数据库的容量。

    select the graph properties to aggregate:指定要聚合的图属性。

    web data aggregation only:表示仅聚合web的数据,在这里可以设置聚合的粒度。

    图3

        3、configure measurements 设置

        在分析图时,发现分析图的Y轴幅值过小时,就可以在这里进行设置,对Y轴进行适当的放大或缩小操作,如图4所示:

    a.手动设置一个比例值;b.使用优化的自动比例来显示图中每个度量;c.将图中所有度量比例都设置为1;d.查看所有度量的趋势。

    默认值 为1,即按原始比例进行显示,有时波形显示的幅值太小,那么就需要适当地调整放大比例。

    图4

        4、设置筛选条件

         如图5所示:在录制测试脚本过程中,如果执行脚本时没有忽略think time时间,那么analysis分析器在统计分析结果时会把think time包含进去,这样当think time存在于用户事务的开始与结束之间时,相关事务统计情况会受到影响。因此,很多时候需要过滤用户的思考时间,在下拉框中删除include think time选项即可,分析结果中就会自动滤掉思考时间。

    图5

    二、analysis图

    analysis分析器中提供了丰富的分析图,如图6所示:

    常见的有8类:

    1)vuses图:在方案执行过程中,vuser在执行事务时生成数据。使用vusers图可以确定方案执行期间vuser的整体行为。它显示vuser状态和完成脚本的vuser的数量。主要包括正在运行的vuser图和vuser摘要图

    2)错误图:主要统计方案执行时的错误信息。主要包括error statistics(by description)、error per second(by description)、error statistics和error per second四种图。

    3)事务图:描述了整个脚本执行过程中的事务性能和状态。主要包括平均事务响应时间图、每秒事务数图、每秒事务总数、事务摘要图、事务性能摘要图、事务响应时间(负载下)图、事务响应时间(百分比)图和事务响应时间(分布)图。

    4)web资源图:主要提供有关web服务器性能的一些信息。使用web资源图可以分析方案运行期间每秒点击次数、服务器的吞吐量、从服务器返回的HTTP状态代码、每秒HTTP响应数、每秒页面下载数、每秒服务器重试次数、服务器重试摘要、连接数和每秒连接数。

    5)网页细分图:主要提供一些信息来评估页面是否影响事务响应时间。包括网页细分、页面组件细分、页面组件细分(随时间变化)、页面下载时间细分、页面下载时间细分(随时间变化)和已下载组件图

    6)系统资源图:主要监控场景运行期间系统资源使用率的情况。可以监控windows资源、UNIX资源、SNMP资源、Antara Flame Thrower资源和SiteScope资源

    7)web服务器资源图:主要用来捕捉场景运行时web服务器的信息。主要用来分析microsoft IIS服务器、apache服务器、iplanet/netscape服务器和iplanet(SNMP)服务器。

    8)数据库服务器资源图:主要显示数据库服务器的统计信息。目前支持DB2、oracle、sql server和sybase数据库。

    图6

    摘要报告               

    一、概要部分

        

    二、统计部分

        

    三、事务统计部分

        

     第一行统计场景运行时所有事务通过、失败、停止的数量。而表格里则是显示了所有事务执行时的详细信息:

    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%,因为如果事务失败率过高,就说明客户在使用系统时很容易出现错误,这样无论事务响应时间多么短也是不符合要求的,因为客户最基本的需求都没有被满足,功能都不能正确的处理,那么更无法谈性能了。

    四、SLA

        

        SLA(service level agreement,服务水平协议)可在性能测试过程中,定义性能测试的目标和度量性能,在性能测试过程中LR会收集和保存性能的相关数据,在分析运行结果时,分析器分将收集的数据与SLA中定义的度量数据进行比较,并将分析结果显示在分析器中,SLA三种状态分别是:

    a.pass:表示SLA获得该项测试数据,并且该数据达到目标要求;b.fail:表示SLA获得该项测试数据,但是测试结果未达到目标要求;c.no data:表示SLA未获得该项测试数据,所以无法确定是通过还是失败。

        SLA配置步骤如下:

    1、在摘要视图中单击如图7所示的按钮:

    图7

    2、单击new,定义SLA目标,如图8所示:

    图8

    3、设置待度量的目标。这里以事务响应时间为例,如图9所示。

        关于事务响应时间的目标有两种方式,一种是按百分比来度量(即设置百分之多少的事务响应时间不能超过目标时间);另一种是按平均事务响应时间来度量。等下依次介绍这2种方式。

    图9

    4、选择事务。(注:在脚本中一定要插入事务,否则在该步选择事务时,无法选择待度量的事务),如图10所示:

    图10

    5、设置百分比阈值。如果是以百分比模式来度量事务响应时间时,如图11所示:

    图11

        该步骤需要设置好百分比和事务响应时间阈值,设置的百分比为90%,事务响应时间为2s,即是只要90%的事务响应时间不超过2s,那么SLA的报告结果即为PASS,否则结果为FAIL。如图12所示。

    图12

        百分比模式,可以在analyze transaction按钮进入分析事务界面,查看详细的分析信息,如图13所示:

    图13

    下面讲一下按平均事务响应时间来度量:

    1、设置负载标准。如果选择按平均事务响应时间来度量,则如图14所示:

         选择负载标准,即通过什么指标来衡量事务响应的变化情况,以运行的虚拟用户数为例,需要设置在不同运行虚拟用户数下事务的响应时间。

    图14

    2、设置阈值。

        选择好负载标准后,需要设置在不同的负载标准情况下,事务响应时间情况,这里即需要设置在不同运行虚拟用户下事务的响应时间情况,如图15所示。

        设置为当虚拟用户数少于10个时,事务响应时间应该不超过1s,当虚拟用户数大于10个时,事务响应时间不超过1.5s。

    图15

    设置到这里就已经全部完成了,可以看出 SLA从本质上来说它是一种目标,是一种度量测试结果是否达到目标的一种手段,与目标场景的设置很相似,原理几乎一致。

        完成SLA设置后,在分析器中会显示出每个度量事务在不同时间域中的结果表现,如图16所示:

    图16

        在此可以选择不同事务、不同时间域进行详细的分析,以查看机票信息为例进行分析,单击analyze transaction按钮分析器会显示出该事务的详细信息,详细分析信息主要包括事务摘要信息、事务相关、错误信息和快照视图。

    1)事务摘要信息

        

    2)事务相关联信息(主要包括显示分析事务时可能需要关联的相关信息:脚本运行时的一些错误信息、系统资源消耗情况、web资源消耗情况和数据库资源消耗情况。)

        注:我的报告中只显示了web资源消耗情况,其实还有上面所提到的其他几种信息的。

        

    3)错误信息(主要显示整个场景运行过程中出现的错误信息,这在与场景运行过程中产生的错误输出信息类似。详细地记录了错误的类型、错误代码、事务名称、脚本、错误代码行数、运行过程中哪个虚拟用户出错 等一些相关的信息)。

        注:因我的脚本运行过程中没有错误,所以在报告中就没有显示错误信息,可自己去操作看一下。

        

    4)快照视图(主要是描述分析的时间域中事务响应时间的情况),如图17所示。

       横坐标表示场景执行的时间,纵坐标表示事务响应时间,图中有3条曲线,红色的表示场景运行时的虚拟用户数,绿色为场景运行时事务的响应时间,黑色表示SLA定义的阈值。如果绿色的线超过了黑色线则说明该点的SLA失败,那么SLA的状态将会置为失败。反之则成功,SLA的状态将置为通过。

     

    图17

     注:按百分比模式与按平均模式的结果显示会有点不同,具体可自行操作分析。

    五、HTTP响应统计

        

        HTTP是一种通信协议,它允许将超文本标记语言(HTML)文档从web服务器传送到web浏览器。HTML是一种用于创建文档的标记语言,这些文档包含到相关信息的链接。可以单击一个链接来访问其他文档、图像或多媒体对象,并获得关于链接项的附加信息。(关于HTTP请求响应机制与HTTP响应状态码的含义,可自行百度,这里就不说了。)

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

    analysis报告               

    一、HTML报告

     

    二、SLA报告

    三、自定义报告

    四、使用报告模板定义报告

    目前还在学习中,希望会对大家有所帮助,觉得不错,就点赞支持一下。 另外,转载时请附带链接。谢谢!
  • 相关阅读:
    UOJ #455 [UER #8]雪灾与外卖 (贪心、模拟费用流)
    Codeforces 482E ELCA (LCT)
    Codeforces 798D Mike and distribution (构造)
    AtCoder AGC017C Snuke and Spells
    HDU 6089 Rikka with Terrorist (线段树)
    HDU 6136 Death Podracing (堆)
    AtCoder AGC032D Rotation Sort (DP)
    jenkins+python+kubectl实现批量更新k8s镜像
    Linux 下载最新kubectl版本的命令:
    jenkins X 和k8s CI/CD
  • 原文地址:https://www.cnblogs.com/dangkai/p/8979416.html
Copyright © 2011-2022 走看看