LoadRunner的两个不一致(Controller和Analysis;Summary Peport和Graphs-Average Transaction Response )

/*

*

* 作者:谷博涛

* 日期:2015-2-26

* E-mail:[email protected]

*

*/

1. 第一个不一致:Controller运行时的实时统计数据和Analysis结果文件中统计数据不一致。

原因分析:Controller实时数据统计的采样频率和Analysis默认的数据统计采样频率可能不同(一般Controller为5秒,Analysis为1秒),因此两者所取得的统计数据的样本不同统计结果也不同;

解决方法:将Controller实时数据统计的采样频率和Analysis默认的数据统计采样频率设置一致;

操作指引:Analysis>选择不一致的图表项>View>Set Granularity>设置同Controller一致;Controller>选择不一致的图表项>Monitors>Online Graphs>Configuration>设置Refresh rate同Analysis一致;

注意事项:该问题还可能由于数据样本采样时间段不一致导致,参照以上方法设置Controller的Graph
Time为 whole scenario可使Controller实时数据统计图表的统计以整个场景采集到的数据为基础;另外是否包含Think time的Filter设置可能导致该问题。

2. 第二个不一致:Analysis查看结果文件时,Reports的Summary Peport 和Graphs的Average Transaction Response Time统计数据不一致。

原因分析:两者计算基于的数据样本空间不同,Reports的Summary Peport统计的数据是基于全部的采样数据计算的,Graphs的Average
Transaction Response Time通常默认是基于图表中的数据点计算的;

解决方法:将Graphs的Average Transaction Response Time图表的统计数据样本空间由"Graph Minimum/Maximum/.../Average"修改为 "Minimum/Maximum/.../Average";

操作指引:Analysis>选择不一致的图表项>View>Legend
Columns Options>依据需要勾选/取消勾选;

注意事项:该问题还可能由于Think
time导致,是否包含Think time的Filter设置可能导致该问题。

注:LoadRunner如实的将我们编写的测试脚本同服务器的交互情况完整的记录了下来,Controller的统计是实时的临时的,Analysis的统计比较灵活,可根据需要调整统计项统计颗粒度以及统计所需的数据样本空间,依据不同的目的可能需要的统计项也不同因此以上的两个不一致未必都需要做成一致的,依据分析的目的不同区别看待,例如有时需要针对特定数据分布作分析时就需要仅针对特定采样频率所采集到的数据因此需要将Graphs的Average
Transaction Response Time图表的统计数据项修改为"Graph Minimum/Maximum/.../Average"。

谷博涛

二零一五年 农历正月初八 下午

http://blog.csdn.net/captain_gbt/article/details/43953623

时间: 2024-12-31 17:30:46

LoadRunner的两个不一致(Controller和Analysis;Summary Peport和Graphs-Average Transaction Response )的相关文章

关于loadrunner的两种录制方式

最近在看loadrunner ,众所周知,loadrunnner有两种录制方式,每种录制方式又包含两种具体的模式,现在来分析一下这几种,以及具体的区别 loadrunner默认使用:HTML-based script这种模式进行录制(mode=html),这中模式下又包含两种具体的方式: 1.A script describing user actions(e.g. web_link,web_submit_form): {基于解释用户行为的脚本,后面提示使用类似web_link.web_subm

LoadRunner中两种录制模式的区别

决定我们成为什么样人的,不是我们的能力,而是我们的选择. --<哈利-波特与密室> 一.先看看两种模式的设置和录制脚本的区别 设置HTML录制模式: 设置URL录制模式: HTML脚本: URL脚本: 从上面的图可以看出HTML模式的脚本精简很多,对于有强迫症的测试工程师来说看上去直观多了. LoadRunner默认录制模式为HTML模式. 两种录制方式优点对比: (一)HTML 录制 优点:减少了捕获动态值的需要. (1)资源从内存中取出且在回放时下载.因此,脚本比其他的录制方式更小且更容易

loadrunner:两参数取同一文件不同列的值

原文地址:https://www.cnblogs.com/Qtoken/p/11326387.html

ANSYS TRANSIENT ANALYSIS [Summary]

1.4. Damping: https://www.sharcnet.ca/Software/Ansys/15.0.7/en-us/help/ans_str/Hlp_G_STR1D.html 8.7. Performing a Nonlinear Transient Analysis: https://www.sharcnet.ca/Software/Ansys/15.0.7/en-us/help/ans_str/Hlp_G_STR8_8.html 5.3. Performing a Full

LoadRunner - 结果分析 / Result Analysis

LoadRunner 最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.针对 Results Analysis 我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助.这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户 要求响应时间是1 个人接管的时间在5S 内. 2.系统资源: 2.1 硬件环境: CPU:奔四2.8E 硬盘:100G 网络环境:100Mbps 2.2 软件环境: 操作系统:英文

具体实例教你如何做LoadRunner结果分析

摘自http://tech.sina.com.cn/s/2009-09-04/10351055931.shtml [IT168 技术文档]1.前言: LoadRunner 最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.针对 Results Analysis 我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助.这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1 个人接管的时间

LoadRunner性能测试样例分析

LR性能测试结果样例分析 测试结果分析 LoadRunner性能测试结果分析是个复杂的过程,通常可以从结果摘要.并发数.平均事务响应时间.每秒点击数.业务成功率.系统资源.网页细分图.Web服务器资源.数据库服务器资源等几个方面分析,如图1- 1所示.性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向.我们回顾一下本次性能测试的目的,正如 所列的指标,本次测试的要求是验证在30分钟内完成2000次用户登录系统,然后进行考勤业务,最后退出,在业务操作过程中页面的响应时间不超过3秒,并且服

Loadrunner测试实例分析

LoadRunner性能测试结果分析是个复杂的过程,通常可以从结果摘要.并发数.平均事务响应时间.每秒点击数.业务成功率.系统资源.网页细分图.Web服务器资源.数据库服务器资源等几个方面分析,如图1- 1所示.性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向.我们回顾一下本次性能测试的目的,正如 所列的指标,本次测试的要求是验证在30分钟内完成2000次用户登录系统,然后进行考勤业务,最后退出,在业务操作过程中页面的响应时间不超过3秒,并且服务器的CPU使用率.内存使用率分别不超过

loadrunner测试结果三

结果摘要: 场景执行情况: 该部分给出了本次测试场景的名称.结果存放路径 及 场景的持续时间 统计信息摘要 statistic summary 该部分给出了场景执行结束后并发数.总吞吐量.平均每秒吞吐量.总请求数.平均每秒请求数的统计值 对于吞量,单位时间内吞吐量越大,说明服务器的处理能力越好,而请求数仅表示客户端向服务器发出的请求数,与吞吐量一般是成正比关系 事务摘要 transaction summary 该部分给出了场景执行结束后相关action的平均响应时间.通过率等情况 http 响应