51Testing软件测试论坛

标题: 用事实说话——解析事务响应时间包括的细分时间 [打印本页]

作者: 大漠飞鹰 时间: 2008-2-14 10:30
标题: 用事实说话——解析事务响应时间包括的细分时间
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 时间: 2008-2-14 13:52
写的挺清楚。不错。
回头想想我原来的理解，是有问题的。
还记得那张图。
响应时间是个比较笼统的词，包括不同的阶段。
像first buffer 的响应时间等等。
所以我们以后说响应时间，要更确切一些了。

作者: 54111 时间: 2008-2-15 11:29
关注中

作者: sayusayme 时间: 2008-2-15 13:28
学习了

作者: iori 时间: 2008-2-15 13:52
期待结果

作者: superfang 时间: 2008-2-18 10:49
标题: 回复 1# 的帖子
那么你的 DNS查询时间怎么能得到呢? CONNECT 怎么获取到?
FIRST BUFFER ?RECEIVE 的时间是怎么得到的!? 可以讲下具体的获取方法吗!?

作者: 冰清 时间: 2008-2-18 11:30
关注中

作者: 大漠飞鹰 时间: 2008-2-27 10:35

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

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

作者: jiang860718 时间: 2008-2-27 11:11
很好啊，谢谢啦！

作者: hilltan78 时间: 2008-3-5 11:46
标题: 事务相应时间
事务相应时间应该是包含RECEIVE 的时间的，但应该没有包含最后将数据解析到浏览器上的这部分时间。

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

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

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

作者: laipi 时间: 2008-4-21 09:18
学习了

作者: yunmenzhe 时间: 2008-5-7 13:35
貌似这个可以解释俺遇到的问题啊。。。。。。一会试试再来给个确切的答案

作者: autumnwjq 时间: 2008-5-19 13:24
哈哈，好贴，学习一下，一会自己实践实践

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

作者: joetree 时间: 2008-5-21 14:50

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

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

总之，受教了！谢谢楼主

作者: peaksoftchen 时间: 2009-5-13 17:00
送了三朵鲜花，不过对于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 时间: 2009-5-18 16:31

作者: liming_oicq 时间: 2009-5-18 22:07
楼主，有一事不明，响应时间里不包括Connection的时间吗？

作者: liming_oicq 时间: 2009-5-19 09:56
顶！！！！！！！！！！

作者: liming_oicq 时间: 2009-5-19 16:09
响应时间里是否包括Connection的时间

作者: liming_oicq 时间: 2009-5-19 22:09
响应时间里是否包括Connection的时间

作者: shanxi 时间: 2009-5-27 09:14
Does LoadRunner transaction response time include the rendering time of the browser?

The answer is “No”! The reason is very simple, LoadRunner is not designed for client-side activities (remember, it’s all about network traffic!). We will illustrate using Web (HTTP/HTML) protocol.
Keep in mind that when we mention rendering time, it means the time taken for the display of the web components, Javascript or applet to load in the browser (or anything that is considered client-activity, loading in the browser) that is being activated after the HTML page is being received.
When we replay the scripts in LoadRunner, network traffic are being generated by the APIs (functions) and are expected to receive before the subsequent step can be executed. All this are taken place in memory and what LoadRunner does is to generate the traffic and receive the responses in memory. No user interface (UI) is launched in the process of replay for the purpose of rendering the pages received. Having no UI launched, rendering is omitted.

In a real user environment, the entire time for response in user perspective includes the request sending time, request processed time, response time and the browser loading (rendering time). However, in the context of LoadRunner, UI is not part of this entire request and response cycle.
Keep in mind that the transmission of the data is still pure text (or binary) and that needs to be rendered by the browser to be displayed properly. That’s considering the Javascript and any applets that needs to be loaded which is greatly dependent on the browser (eg. IE, Modzilla)and your machine specifications.
Even for Web Page Diagnostics, rendering time is not included as part of the transaction response time. It only allows the drill-down of time taken to download web components and not the time taken to render the component for display. In summary, it’s still at the network level.
If you are looking for an end-to-end response time testing that includes the rendering of the UI, you should consider using the GUI vuser protocol. The protocol utilizes another (famous) HP testing product, Quick Test Professional (QTP) as the recording mechanism, and replays the QTP scripts in the Load Generators as GUI vusers. For official information on the GUI vuser protocol, you can refer to the HP LoadRunner (v9.0) Controller User Guide, Chapter 14, “Using Functional Testing Scripts in LoadRunner”.

一个佐见，至于作者的依据有何根据，可以发邮件去问问。

作者: 淑女一点点 时间: 2009-5-27 09:49
写的很好,我也有同样的疑问.

作者: liming_oicq 时间: 2009-5-27 10:51

作者: badhj 时间: 2010-10-22 18:26
到今天了，有个确切的权威的答案吗

作者: dllnetspy 时间: 2010-10-22 23:55
学习一下支持

作者: cjp110212 时间: 2010-10-23 16:22
学习了！！

作者: blueyonder 时间: 2010-10-23 16:31
很受用，谢谢

作者: ljonathan 时间: 2010-10-24 11:55
这个得留名看

我一直理解的是，从客户端发出请求开始算起，到服务端返回第一个字节，这段时间就是响应时间
看来需要做个试验验证

作者: ZH_0211 时间: 2010-10-27 14:38
受教了

作者: nzz0102 时间: 2011-9-24 13:49
今天还没有答案么？

作者: senseflower 时间: 2011-11-16 16:37
一种猜想，事务没有执行成功，所以总时间中根本不存在First Buffer time

作者: yuandxie 时间: 2011-11-21 17:41
DNS解析时间、connection、 First　Buffer、 Receive、 Client Time这几项各自的平均值相加，有时不等于事务响应的平均时间吗？

作者: ymwang119 时间: 2011-11-23 11:25
楼主写的真好，拜读

作者: yushudd 时间: 2012-1-18 16:16
先留个记号有空仔细研究一下。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)