转:LR的响应时间与使用IE所感受时间不一致的讨论

在做性能测试时,有时碰到这样一种情况,使用性能工具LR测试出来的响应时间比实际使用IE感受到的时间要长,例如,实际使用IE打开一个系统时只需要1~2秒,而使用LR跑一个用户所得出的结果可能是8秒、10秒、或者更大的响应时间。

针对上述问题进行分析总结,有3种情况:
1、在运行LR场景时没有忽略Think Time(思考时间)和记录log的时间;
2、**或服务器的机器配置不高,比如低配置的机器在运行场景工具时系统资源已满,则造成响应时间过长。
3、实际IE感受的时间不等同于LR录制的响应时间。

前两中情况可以通过LR设置及提高硬件配置解决。
       第三种情况,因为LR在录制过程中,事物的响应时间包括:DNS Resolution、Connection、First Buffer time、Receive Time、Client Time时间等,比如当我们在使用IE打开页面时,系统首先会进行域名解析,并与服务器建立连接、下载数据,到这时在IE中已可以显示页面,但实际响应时间并没有结束,浏览器仍有可能在与服务器进行数据交互,或者客户端IE由于忙碌未及时将请求发出,出现了客户端延时情况(客户端IE会执行一些javascript脚本或其他页面初始化动作),直到这些动作全部完成后才是一个完整的响应时间,LR也是记录的这个响应时间。

所以我们通常使用IE所感受到的时间是比用性能工具录制时记录的响应时间要少。因此,系统页面的响应时间应以工具记录时间为准,并在分析报告中查看平均事物响应时间。

toone
--------
对时间的解释:
1、DNS Resolution:浏览访问一个网站的时候,一般用的是域名,需要DNS服务器把域名解析为IP地址,这个过程就是域名解析时间。
2、Connection:解析出WebServer的IP地址后,浏览器请求被发送到了一个Web Server,然后浏览器和Web Server 之间需要建立一个初始化的HTTP连接,服务器端需要做两件事:一个是接收请求,二是分配进程。建立该连接的过程就是Connection。
3、First Buffer:建立连接后,从Web Server发出第一个数据包,进过网络传输到客户端,浏览器成功接收第一个字节的时间就是First Buffer。
4、Receive:从浏览器接收第一个字节起,直到成功收到最后一个字节,下载完成为止。
5、Client Time:请求在客户端浏览器延迟的时间。

在实际使用LR做页面请求响应时间时,我采取的是下载页面,清除IE缓存,每次都是不同用户浏览,所以对服务器的压力比较大,每秒的请求数居高,但是得到的responsetime确实比手动的时候大了很多,个人认为,图片在加载过程中及CSS样式文件,都是同步在加载,但是对IE客户端来说,人的视觉首先会看到图片,然后才是样式的出现,所以感觉上要快,因为看到的是一个动态过程,但是对LR来说,它只关心,从第一次请求到最终结束请求的时间,因此时间上会比实际操作时要长。

举个例子,或许就是一个图片链接,但是他加载的可能一个超级链接,但是这个链接又是用ajax来实现的,另外还带有CSS,但是对IE端用户来说,只要看到图片就认为加载完毕了!

时间: 2024-11-12 16:28:31

转:LR的响应时间与使用IE所感受时间不一致的讨论的相关文章

LR的响应时间与使用IE所感受时间不一致的讨论

在做性能测试时,有时碰到这样一种情况,使用性能工具LR测试出来的响应时间比实际使用IE感受到的时间要长,例如,实际使用IE打开一个系统时只需要1~2秒,而使用LR跑一个用户所得出的结果可能是8秒.10秒.或者更大的响应时间. 针对上述问题进行分析总结,有3种情况: 1.在运行LR场景时没有忽略Think Time(思考时间)和记录log的时间: 2.测试机配置不高,比如低配置的机器在运行场景工具时系统资源已满,则造成响应时间过长. 3.实际IE感受的时间不等同于LR录制的响应时间. 前两中情况可

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

在新一代一期项目非功能测试过程中,我们发现了LoadRunner测试响应时间与客户端实际用户体验时间不一致的现象.例如员工渠道上线后,客户体验时间远远超过了LoadRunner测试响应时间.本文针对这一现象深入研究了导致二者不一致的原因并提供了意见和建议,现与大家分享. 1.用户体验时间 用户通过浏览器访问Web服务器时,体验时间可以细化.如下图所示,体验时间包括用户感应时间.浏览器处理时间.网络传输延时和后端服务器处理时间. 2.LoadRunner单次事务响应时间度量 我们通常将核心业务操作

lr总结

最近一直在用Loardrunner做性能测试,记录下自己在工作中遇到的问题. LR的基本设置 首先是录制,在录制前选择TOOLS-recording options 在General中选择recording方式HTTP协议的选择HTML-based script方式,如果是HTTPS协议选择URL-based script方式:选择HTTP  propertie-Advanced,support charset选择UTF-8,此处如果在回放过程中,还是有乱码,检查被录制代码中是否有编码不是UTF

LR Analysis:详解FirstBufferTime

LR Analysis:详解FirstBufferTime 详解 第 一次缓冲时间 测试结果分析过程中,经常遇到第一次缓冲时间 FirstBufferTime,并且发现大 部分系统的响应时间也都浪费在了这里,再给研发解释这个问题时候,又不能拿 FirstBufferTime 直接给研发说,抽时间整理了下,希望对大家有用以下资料来自 LR 帮助手册:定义: 第一次缓冲时间细分图显示成功从 Web 服务器返回的第一次缓冲之前的这一段时间内,每个网页组件的相关服务器/网络时间(以秒为单位) 网络时间:

转载-LR Analysis:详解FirstBufferTime

详解 第 一次缓冲时间 测试结果分析过程中,经常遇到第一次缓冲时间 FirstBufferTime,并且发现大 部分系统的响应时间也都浪费在了这里,再给研发解释这个问题时候,又不能拿 FirstBufferTime 直接给研发说,抽时间整理了下,希望对大家有用 以下资料来自 LR 帮助手册: 定义: 第一次缓冲时间细分图显示成功从 Web 服务器返回的第一次缓冲之前的这 一段时间内,每个网页组件的相关服务器/网络时间(以秒为单位) 网络时间:从发送第一个 http 请求那一刻直到收到确认为止,所

LoadRunner 思考时间与事务响应时间的区别与关系

LoadRunner 思考时间与事务响应时间的区别与关系   思考时间lr_think_time 就是一个事务要开始时思考的时间;比如 你要点击一个 登录按钮 我们都要点击这个按钮要先思考下 就是人为脑袋思维的延迟,还有手指点击鼠标的这个动作的时间 一般是1-5秒,这就是思考时间,性能测试模拟思考时间就是模拟真实人为动作的方式来做压力测试.一般在脚本中思考时间是这样写比较合理,在一个事务的结束点另一个事务的起始点,两者中间定义思考时间.lr_end_transaction("登录",

性能测试瓶颈判断(LR&Windowns)

一.判断CPU瓶颈(Processor) 1, %processor time 如果该值持续超过95%,表明瓶颈是CPU.可以考虑增加一个处理器或换一个更快的处理器. 如果服务器专用于sql server,可接受的最大上限是80-85% 2,  processor queue length大于2 (大于处理器个数+1).可以确定CPU瓶颈 如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.

loadrunner自学以及问题解答2

QQ群:2423597857 ============================== 46.LR启动controller报错"transaction monitor not available" 1.多是OS系统问题,修复试试或升级 2.或修复LR试试 47.Loadrunnber 报错误:Error -- memory violation : Exception ACCESS_VIOLATION received.的一种情况 Posted on 2011-01-05 12:12

【转】朱兆祺带你一步一步学习嵌入式(连载)

原文网址:http://bbs.elecfans.com/jishu_357014_2_1.html#comment_top  从最初涉及嵌入式Linux开始到现在,深深的知道嵌入式的每一步学习都是举步维艰.从去年11月份开始,我就着手整理各种学习资料,希望推动嵌入式学习的前进贡献自己微不足道的一份力量.从去年到现在,将C语言的学习经验整理成<攻破C语言笔试与机试陷阱及难点>(现在仍在更新),这份资料已经在电子发烧友论坛的单片机论坛连载(http://bbs.elecfans.com/jish