Loadrunner Analysis之Web Page Diagnostics
作者：tacy lee简单介绍一下Loadrunner Analysis中的Web Page Diagnostics模块的使用，很多人对于测试之后的结果数据分析摸不着头脑，其实loadrunner Analysis给你提供了很好的文档，大家没事可以多翻翻，多翻几遍对于性能测试你就入门了 ；）
Web Page Diagnostics （以下简称WPD），这是LR Analysis中非常重要的一块，搞清楚这部分的内容会让你少走很多弯路，很多环境问题都可以通过它来定位，比如客户端，网络。通过它可以你可以比较好的来定位是环境的问题还是应用本身的问题，当然更重要的是Web页面本身的问题。
WPD包括下面几个图表：
Web Page Diagnostics 这是张总图，包括下面几张Over Time图的内容
Page Component Breakdown 页面中每个元素的平均响应时间占整个页面响应时间的百分比
Page Component Breakdown(Over Time) 在整个测试过程中，任意一秒内页面中每个元素的响应时间（例如在runtime中设置了browser cache，页面中的资源文件就只会在第一次下载，后面的页面响应时间也就不包括这些元素的时间，这在Page Component Breakdown中是看不出来的，因为Page Component Breakdown是整个测试期间内的平均时间。当然，是否启用了cache，通过over time图就能看出来）
Page Download Time Breakdown 页面中每个元素的响应时间分割图，响应时间被分割为以下几个部分：DNS Resolution,Connection,First Buffer,SSL Handshaking,Receive,FTP Authentication,Client,Error
Page Download Time Breakdown(Over Time) 在整个测试过程中，任意一秒内页面中每个元素的响应时间分割图
Time to First Buffer Breakdown First Buffer Time时间分割为Network Time和Server Time，客户端http请求发送到接收到服务器端的应答包（ACK）为Network Time，从接收到ACK到完成First Buffer接受为Server Time
Time to First Buffer Breakdown(Over Time) 基本同上，任意一秒内的
Downloaded Component Size(KB) 页面中每个元素的大小（KB）
介绍了这么多，具体如何分析呢？
首先打开Web Page Diagnostics图，来看看下面一个例子Download Time图：
http://www.blogjava.net/images/blogjava_net/tacy/WindowsLiveWriter/LoadrunnerAnalysisWebPageDiagnostics_10C05/Web-Page-Diagnostics-DownloadTime_2.png
上图存在两个问题：
1、receive时间很长
这个一般是网络问题，当然如果你确认网络不存在问题，那么你就要看看是不是客户端的问题（客户端也可能会造成Receive过长，这个千万要注意）
2、页面问题
页面上包括了非常多的图片，而且图片似乎都没有优化，最大的竟然有163K，记下来，这可是罪证哦 ；）
很多时候，你可以根据DNS,Connection,Receive来看出是否存在网络问题，根据Client来判断是否存在客户端问题。
看看，挺简单的吧！ ^_^
换个图看看，Page Component Breakdown(Over Time)
http://www.blogjava.net/images/blogjava_net/tacy/WindowsLiveWriter/LoadrunnerAnalysisWebPageDiagnostics_10C05/Web-Page-Diagnostics-PCB_2.png
很清楚吧，页面元素都被cache了，说明场景启用了browser cache，页面的响应时间只包括红线和蓝线。
Time to First Buffer Breakdown(Over Time)，图就不贴了，这个图非常重要，也最复杂，这里的值不绝对，当网络状况不好的时候，server time很可能包括网络时间，因为很多页面元素比较小（小于4k的样子），在First Buffer就完成传输，所以一定要注意分析。
就唠叨到这里吧，欢迎拍砖 好像讲的太少了些
呵呵 还是谢谢版主 挺好。 开了不错一个头
继续 ^_^ 根据以往的经验，很多测试人员都死在环境问题上，这也是有特殊原因的，一般公司都不能提供完备的测试实验室，经常是随便找机器来测试，这个时候你就一定要注意，wpd会帮你定位很多问题 分析得不错 恩，很好 我要向楼主学习。 只开了个头啊，楼主再辛苦辛苦，能不能把最后一点：Time to First Buffer Breakdown(Over Time)，深入讲讲呢？
赫赫，辛苦辛苦 time to first buffer breakdown(over time)仔细抓包分析了一下，感觉自己也没搞清楚，举个例子吧
一个页面，包括五个图片，2个css，2个js
每一个元素都会产生一个http请求，一个请求发出，server端直接回传数据了（tcp连接已经建立），不知道lr中说的接受到ACK应答从何而来，下面是lr doc原文：
Network time is defined as the average amount of time that passes from the moment the first HTTP request is sent until receipt of ACK.
当然client会发送ack到server，告诉server你之前发的包我收到了，如果和server的不匹配，server会从client请求的seq重传（要搞清楚的最好看看tcp/ip机制）
我仔细看了一下，实在没发现这里面的network time和server time具体如何划分，希望清除其运行机制的人解释一下 ；）
我现在的理解是不看server time 和network time， :) 快被networktime整晕了:Q 顶一下，看大家还有什么见解。 现在点了这个都没数据了，怎么办 右击average transaction respose time 后找不到，通过add graph后增加的，没有数据，为什么啊 回复 1# tacy_lee
"当网络状况不好的时候，server time很可能包括网络时间，因为很多页面元素比较小（小于4k的样子），在First Buffer就完成传输"-------这句话能再解释一下吗？不太明白
页:
[1]
