loadrunner 中的响应时间和实际不符合这是为啥

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了loadrunner 中的响应时间和实际不符合这是为啥相关的知识,希望对你有一定的参考价值。

参考技术A 检查下你的事务做的可对,开始和结束是否是你想要统计的部分。
另外,在运行时设置中,有很多选项都是会影响到响应时间的,比如日志的输出,thinktime,静态资源,缓存等等。要仔细检查

转:LoadRunner响应时间与用户体验时间不一致问题的深入分析

在新一代一期项目非功能测试过程中,我们发现了LoadRunner测试响应时间与客户端实际用户体验时间不一致的现象。例如员工渠道上线后,客户体验时间远远超过了LoadRunner测试响应时间。本文针对这一现象深入研究了导致二者不一致的原因并提供了意见和建议,现与大家分享。

1、用户体验时间

用户通过浏览器访问Web服务器时,体验时间可以细化。如下图所示,体验时间包括用户感应时间、浏览器处理时间、网络传输延时和后端服务器处理时间。

技术分享

2、LoadRunner单次事务响应时间度量

我们通常将核心业务操作定义为事务,在LoadRunner脚本中具体为web_url()、web_submit_data()等函数调用。下面举例计算单个事务响应时间,定义一次web_url()调用为事务,web_url函数中请求4个文件。

技术分享

LoadRunner获取每个资源都要经过反应、第一次缓冲和接收三个阶段,反应阶段包括DNS解析、建立初始连接、SSL握手、FTP认证;第一缓冲时间是显示从初始HTTP请求(通常为GET)到成功收到Web服务器返回的第一次缓冲所经过的时间;接收时间显示在服务器发出的最后一个字节到达,即下载完成之前所有的时间;客户端时间显示由于浏览器反应时间或其他客户端相关延迟而导致请求在客户机上延迟的平均时间。

技术分享

LoadRunner执行web_url()语句时,请求资源的先后顺序不依赖代码书写顺序,导致很难直接确定执行web_url()的开始时间,但可以借助LoadRunner的分析工具模块页面诊断器(Web Page Diagnostics)获取事务开始时刻和结束结束。在Web Page Diagnostics中可以获取资源下载完成时刻(Scenario Elapsed Time)和花费时间(Page Component‘s Download Time),二者之差即为资源下载的开始时刻,资源开始下载的最小时刻为事务的开始时刻;在Web Page Diagnostics中资源下载完成时刻(Scenario Elapsed Time)最大值为事务的结束时刻。结束时刻与开始时刻之差为单次事务响应时间。LoadRunner单次事务响应时间取决于资源下载时间的最大值,下载时间包括第一次缓冲时间、接收时间等。

3、结论与建议

综上所述,LoadRunner测试响应时间不包括用户浏览器的JS文件解析执行、渲染、布局、绘制和人眼识别所需时间,只包括网络延时和后端服务时间。这也从侧面说明LoadRunner主要用来测试后端服务器性能和处理能力。LoadRunner测试时间与用户体验时间的差异如下表:

 

 

技术分享

一般情况下LoadRunner测试的响应时间小于用户实际体验时间。

针对后续非功能测试,本文提出以下测试建议:

(1)如果测试目的要求获取用户体验时间,需要在LoadRunner测试响应时间的基础上考虑添加误差因子;

(2)如果用户实际体验的时间远大于LoadRunner测试响应时间,需要重点分析排查JS解释执行、渲染等问题;

(3)如果LoadRunner测试响应时间较长,可以借助First Buffer Time、Client Time、Receive Time等分析确认网络问题、后端服务问题和页面元素问题。

 

原文:http://www.tansun.com.cn/tyhy/96249/97930/index.html

以上是关于loadrunner 中的响应时间和实际不符合这是为啥的主要内容,如果未能解决你的问题,请参考以下文章

loadrunner-检测到的响应时间远小于用户实际查询时间。 哪位大神能帮忙看看?急急急~!

loadrunner性能测试的时候,测试的事务响应时间比实际情况的值还要大。这个是啥原因?

为啥loadrunner用场景压出来的响应时间会比直接在ie里面操作或者脚本回放慢很多?

用loadrunner 做压测,响应时间比实际要高很多,为啥 · TesterHome

LoadRunner参数化

LoadRunner 事务响应时间