binflying 发表于 2009-7-11 16:58:39

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：解析出Web Server的IP地址后，浏览器请求被发送到了一个Web Server，然后浏览器和Web Server 之间需要建立一个初始化的HTTP连接，服务器端需要做两件事：一个是接收请求，二是分配进程。建立该连接的过程就是Connection。
3、First　Buffer：建立连接后，从Web Server发出第一个数据包，进过网络传输到客户端，浏览器成功接收第一个字节的时间就是First Buffer。
4、Receive：从浏览器接收第一个字节起，直到成功收到最后一个字节，下载完成为止。
5、Client Time：请求在客户端浏览器延迟的时间。
----------------------------------------------------------------------

有高手对上述问题有质疑的请跟帖回复，欢迎大家对这个问题进行讨论。thx，也可以直接发我邮箱mobin2008@foxmail.com

shanxi 发表于 2009-7-13 14:31:32

性能测试都是主观的

qiuyangzh 发表于 2009-7-15 10:23:28

这些因素确实都会影响
现在的web系统，在页面上一般都会进行处理，分块加载，会让用户在使用的时候感觉速度较快
如果确实对响应时间比较怀疑，可以选用2款不同的工具测试一下，对比结果

xinliduo 发表于 2009-7-24 10:39:47

我也碰到过这个问题用 jmeter 测 500用户并发 平均响应时间是3秒，而用LR平均响应时间是12秒 压力机资源在压的过程中都是60%以下。也不是分布加载页面，手工页面发请求的话 感觉也只有3秒多

sunhope800 发表于 2009-7-24 12:27:37

:handshake

本来就很乖 发表于 2009-7-29 15:13:23

原来是这样的啊，:lol，谢谢

zishuijing 发表于 2009-11-13 18:03:41

不同的测试机测试同一个脚本，得到的响应时间不同

遇到同样的问题，不同的测试机，测试同一个脚本，得到的响应时间不同。一个是1s左右，一个是8秒左右，相差比较大。 在局域网内应该不是网络的问题。

wwwux 发表于 2009-11-14 14:32:29

还有关键一点，IE观察要清除缓存

liangyingjie 发表于 2009-11-18 11:09:35

支持，呵呵，不错的东西啊

yay 发表于 2009-11-23 16:35:34

正在为这事儿发愁呢,跟客户解释不清楚..正好看到这篇文章..

fiskeryang 发表于 2010-8-2 17:21:40

不错顶一个

msnshow 发表于 2010-8-2 21:46:53

IE本身对内容的解析也需要时间的

kuangquanshui 发表于 2010-8-3 08:44:21

浏览器会有一个提示表示   当这个表示显示为完毕的时候是不是就可以说   浏览器端和服务器端的交互完全结束了？

zjx01206 发表于 2010-8-3 11:12:40

原来是这样啊

SSunny 发表于 2011-8-11 11:36:54

工具计算到的时间包含了域名解析，从客户端发出请求，服务器接收请求，进过一系列的处理，然后再放回给客户端，到整个接收完整页面所有信息为止，所以工具测出来的时间比人工主观感觉的时间长。

SSunny 发表于 2011-8-11 11:37:18

工具计算到的时间包含了域名解析，从客户端发出请求，服务器接收请求，进过一系列的处理，然后再放回给客户端，到整个接收完整页面所有信息为止，所以工具测出来的时间比人工主观感觉的时间长。

gongdao96 发表于 2011-8-11 22:35:43

回复 1# binflying


    请问lz是否遇到过lr响应时间要小于实际使用IE的感受时间呢？
我最近一个压力测试就遇到此类问题，lr单用户记录指定事件平均响应时间为0.5秒左右，而实际使用IE感受事件却在5秒左右。

gongdao96 发表于 2011-8-11 22:46:07

回复 17# gongdao96


    分析以上原因，首先是该应用使用了struts2 +spring +hibernate+Tomcat;服务端的实际数据处理较为简单（从page down分析得来），返回时间相当快；而实际处理压力是由客户端产生的（要将数据分解并表格显示同时还要支持第三方插件的双击显示等等），处理显示时间相当慢（在录制脚本中插入检查点无效），而个人认为lr记录的响应时间是不包含客户端收到服务器返回信息进行处理至屏幕显示的时间的，不知对否？

村上舞!舞!舞 发表于 2012-5-30 18:43:04

正解，客户端处理LR性能测试时是并不包含客户端解析返回页面代码时间的，所以对于胖客户端系统，压力需要客户端承担一部份，从而减轻了服务器的处理程度。而LR性能测试主要测试了服务器的处理性能。在实际使用过程中，客户端是分散的，不需要承担并发访问的压力。而服务器是集中承担访问压力的。
页: [1]
查看完整版本: LR的响应时间与使用IE所感受时间不一致的讨论