用事实说话——解析事务响应时间包括的细分时间

大漠飞鹰

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：请求在客户端浏览器延迟的时间。

Zee

写的挺清楚。不错。
回头想想我原来的理解，是有问题的。
还记得那张图。
响应时间是个比较笼统的词，包括不同的阶段。
像first buffer 的响应时间等等。
所以我们以后说响应时间，要更确切一些了。

54111

关注中

sayusayme

学习了

iori

期待结果

superfang

那么你的 DNS查询时间怎么能得到呢?   CONNECT 怎么获取到?
FIRST BUFFER  ?RECEIVE 的时间是怎么得到的!? 可以讲下具体的获取方法吗!?

冰清

关注中

大漠飞鹰

原帖由 superfang 于 2008-2-18 10:49 发表
那么你的 DNS查询时间怎么能得到呢?   CONNECT 怎么获取到?
FIRST BUFFER  ?RECEIVE 的时间是怎么得到的!? 可以讲下具体的获取方法吗!?

见第一楼，文中已经说明。

jiang860718

很好啊，谢谢啦！

hilltan78

事务相应时间应该是包含RECEIVE 的时间的，但应该没有包含最后将数据解析到浏览器上的这部分时间。

renheyou

鄙人觉得Cache的作用也是很关键的，第一次DNS查询时肯定是要耗费时间的，第二次再访问时，则不用查询直接调用DNS Cache里的IP 来使用，这样前后两次的总时间应该是不一样的。
但是针对某一次的访问来说，Cache的作用也可以不用考虑，最多就是总时间多点。

总之，把HTTP协议和其他网络协议多了解点就可以帮我们更好地理解问题
我认为事务相应时间应该是包含RECEIVE 的时间的，这样具有实际意义，因为只有内容都显示出来了才算是一个完整的访问过程。

msnshow

LoadRunner的性能数据采集是使用取点的方式，所以出现“试验三”中的结果并不奇怪

laipi

学习了

yunmenzhe

貌似这个可以解释俺遇到的问题啊。。。。。。一会试试再来给个确切的答案

autumnwjq

哈哈，好贴，学习一下，一会自己实践实践

tianjiao920

经常可以看到响应时间中First Buffer占绝大部分比重。。。。。
也就是说忽略其他参数。。。。First Buffer应该与响应时间相差不大，，但应该不会超过响应时间

joetree

原帖由 msnshow 于 2008-4-20 19:18 发表
LoadRunner的性能数据采集是使用取点的方式，所以出现“试验三”中的结果并不奇怪

我觉得只有这个解释看起来比较符合“试验三”的情况
而且可以从楼主的实验里面看出来 cache 有很大关系，估计是一个是取点得到结果，一个又是取一定时间的平均值，然后导致这样的情况

总之，受教了！谢谢楼主

peaksoftchen

送了三朵鲜花，不过对于FirstBuffer定义有点疑义，感觉不是第一个字节的时间。下面是我在帮助中找到的关于Page Download Time Breakdown Graph中First Buffer的定义：

Displays the amount of time that passes from the initial HTTP request (usually GET) until the first buffer is successfully received back from the Web server. The first buffer measurement is a good indicator of Web server delay as well as network latency.
Note: Since the buffer size may be up to 8K, the first buffer might also be the time it takes to completely download the element.

印象里通常大小都是8K，而多数图片外的网友元素可能都小于8k，所以First Buffer可能就是当前元素的大小。

建议楼主结合HTTP协议中网页获取过程再分析一下，可能会更透彻。

[ 本帖最后由 peaksoftchen 于 2009-5-13 17:09 编辑 ]

witcher2002

liming_oicq

楼主，有一事不明，响应时间里不包括Connection的时间吗？