在做性能测试时,有时碰到这样一种情况,使用性能工具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端用户来说,只要看到图片就认为加载完毕了!