|
08年春节前和zee的通话中被告知LoadRunner中的事务响应时间不包括Receive Time,当时甚为惊诧,因为我一直是认为事务响应时间应该包括DNS Resolution、Connection、First Buffer、Receive、Client Time等时间的。如果LoadRunner结果分析中的事务响应时间的确不包括Receive Time,那也就意味着我曾写过的许多系统性能报告很多都将成为废纸。 但是zee也没有拿出足够的证据证明他的理解是绝对正确的。
为了明确事务响应时间是否包含Receive time在内,我在网上查了很多帖子和文章,这一查吓我一跳,因为网络上对事务响应时间以及其细分时间的理解存在很大的分歧,而且并没有统一的或者一致的观点和说法。我罗列几种常见理解分歧:
1. Client time指客户端发出请求前的延时(客户端忙碌未能及时将请求发出),还是收到请求后的客户端延迟(客户端IE会执行一些javascipt脚本或其他页面初始化动作)
2. First Buffer time 是否包括DNS Resolution Time 和Connection Time,有人甚至认为First Buffer time 就是事务响应时间,因为First Buffer Time在LoadRunner中是这样解释的:Displays the amount of time that passes from theinitial HTTP request (usually GET) until the firstbuffer is successfully received back from the Webserver. The first buffer measurement is a goodindicator of Web server delay as well as networklatency. 如果这里的HTTP request 理解为客户端提交HTTP请求,那么他的这种理解还真是有一定道理的。
3. Average Transaction Response Time 是否包括Receive time 和Client time
先说第一个问题,Client Time的理解。按kernzhang的说法,这一时间指收到请求后的客户端延迟(客户端IE会执行一些javascipt脚本或其他页面初始化动作),我自己也是这样理解的。但是在LoadRunner中并没有找到足够的说明来解释这一点,只是说是客户端的延迟。
再说第二和第三个问题。第二和第三其实是同一类问题,我没有找到相关的足够的证据说明那个对那个错,因此我设计了如下的一个试验。
思路:Analysis中有两张表,Average Transaction Response Time和Page Download Time Breakdown(Over Time),而且能生成原始数据,生成Average Transaction Response Time中的 Raw Data,然后生成Page Download Time Breakdown (Over Time)中的Raw Data,将相同时间点的事务响应时间和事务的各种时间做一个比较。例如从开始执行起到2.035秒有一个action事务,响应时间为3秒,然后到Page Download Time Breakdown (Over Time)中找2.035秒action事务的各个时间,包括DNS Resolution、Connection、First Buffer、Receive、Client Time,对比这些数据做对比分析,主要是将细分时间累加,然后和事务响应时间做比较。
脚本:访问http://www.51testing.com,录制在Action中(为了分析的简便,我只保留了一个web_url,删除了另外一个web_url)
场景:Vusers:1
Run Mode:Run until complete
Think Time:lgnore
Run Logic:run *20 action
试验一:
运行时设置中将“Simulate a new user on each iteration”的选项取消,执行测试。对照Average Transaction Response Time和Page Download Time Breakdown(Over Time)的数据。
结果:除第一个事务外,发现First Buffer + Receive + Client Time = 事务响应时间;
试验二:
运行时设置中将“Simulate a new user on each iteration”的选项选中,“Clear cache on each iteration”不选中,执行测试。对照Average Transaction Response Time和Page Download Time Breakdown(Over Time)的数据。
结果:除第一个事务外,发现First Buffer + Receive + Client Time = 事务响应时间;
从试验一和试验二,我们可以确定事务响应时间是包括First Buffer Time、Receive Time和Client Time的。
试验三:
运行时设置中将“Simulate a new user on each iteration”的选项选中,“Clear cache on each iteration”也选中,执行测试。对照Average Transaction Response Time和Page Download Time Breakdown(Over Time)的数据。
结果:Page Download Time Breakdown (Over Time)中的时间无论怎么加都不等于事务的响应时间,有时候细分时间累加大于事务响应时间,有时则小于事务响应时间,有时事务的First Buffer Time竟然大于事务响应时间。
我无法解释为什么会出现这种现象,特别是事务的First Buffer Time竟然大于事务响应时间,这是我所不能理解的,难度是LoadRunner的计时上存在问题?我认为事务的响应时间应该是通过细分时间的计算得出的,如果细分时间不准确,那么LoadRunner就是彻头彻尾的大骗子,按理说应该不至于。谁要是能解释原因,请跟帖,谢谢!
附页面细分时间的解释
1、 DNS解析时间:浏览访问一个网站的时候,一般用的是域名,需要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:请求在客户端浏览器延迟的时间。 |
|