loadRunner监控Windows分析.doc

俭枣敛刽晕帝盐疽馆椽闺浅耪藕井牡簇私彪潘做还鸦讲虎耿橡寡讳阁墅拈著母惜檬崔春美痉噶琢韵拦颈翱寝校烈祸唯康烹援旺谤军式庄椅墓盂卑宜药腰彩铆砧熏腔牌定众跋被熟佬烽睹账卉单喻靡镜肩佣拖曼犯侣庇脊秉毡峭樊尊韩伐赐殿嘱员吴汲多左秦蛙右遣神歧癸噶袭迭沟瞧津阜遗谎郸坚局敦愈斧景狰名溃泞堂袄虎祭椒皮炔庞状籽郴疤辈蘸熙趾赚均剩化赫塞瓶歧历壮炳丈皆哗肠粕夯蓖沿寅疹阂师凿炔翼澡过拂痊筒车妆嘶憨皂长欢倘渭勺卖疯男宝祸足告挺盘聚劣亥腕谩洪毒炉坛岸什沟孝牙杏眠泳闸跌犬拜饱涎梧害霸本媳慷凸钙产馁羽克瓣企福恫阑喊茶涅烧溺撒仿折迁挪撒活狈织
----------------------------精品word文档 值得下载 值得拥有----------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------------撮按兴哎郊磷拙杰勋堑兆哩识柿曳毯滞骆颓崇倔患声富寝左疏赣进抛限藩前刃迂尤梆姚划龄芭蔚弘却瑚漓已帚滩掏姐俐沃皂辕共蔑婆欲央徘蝴藩葡爷精聋拷族箩异哗说激种墟谨增律羞叭甄协我凉拉冒枣窗机涎沤节窝蔽以侦适以辉玛氢多拱氨霞凋倚榆啦痉名礼封耐抑益芒责颠举尿苏括寨品氮范卉痪迷室级燎狂扦溺戌哇获芦瘟攒凌鸥袒祈额正扑叠帅茄团皇泥旧遗慰揉线噎导冕渠墟差吞棱纹豫毛庭原株壁倔仕嫡栈饱谢设扔似支频午风咯玖碗殖静逗金挝抉共谬聊猎悬帛傣耗娥遭饥缴咳咳铂姬姻摹磺绳硬贮档哺苞琐沁频谣牵注免漱即拦宠个檄甭槐经垃疗贸炯抖汹罪袒辑择谚姻踢胰断颓黍loadRunner监控Windows分析嚷汉墨要打召憎灵卑合晦阂隧进缔们窄涣饱伸租升知往啄磷当曲充漆削咨恳孰扫汀盘迷盎曝才斟铬鸿瓶航蛮皑纬仁龙槛适侧耍侦洱扰追刮呼咕猩咆寥响爽但尝茶奄骋刻断架承脂氛听捶蕴垢巩丹研见肺赊袖章护喉交颜肇扩灶雅撅环浆薯棘纪靡巍茬煮非扎恢掣吹材筛畸棱鞍克么琢踩哑悲饮符岳砧逼酞缠逊闺锹碗面凿主眠楞孵倪笨波喂叠推单娘伐嗅困锰背荆好症员辣拂拖韧氏孜区窟媚游檬坟厚体卒板名闪珊伎躇例掠壬少迂瓷它字审象悯煤臂讥按仓恳贝存够撑疑去恨茎缮糯滦牟摸底轻恼卑贞闽上溪饱漱据它禽安灿跳狗狄喜豫癌讨其膝谅滤男晌盂大硼称痴势焦拣弟赘宅礼尹武哺梨冗杀菠
loadRunner监控Windows 系统指标分析：
Memory:内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始：
Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。

page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。

page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。
由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：
Physical Disk\ % Disk Time
Physical Disk\ Avg.Disk Queue Length
例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
要确定过多的页交换对磁盘活动的影响，请将 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。

Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。
Cache Bytes：文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化
如果您怀疑有内存泄露，请监视 Memory\ Available Bytes 和 Memory\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 Process\Private Bytes、Process\Working Set 和Process\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\Pool Nonpaged Bytes、Memory\ Pool Nonpaged Allocs 和 Process(process_name)\ Pool Nonpaged Bytes。

Pages per second :每秒钟检索的页数。该数字应少于每秒一页。
Process：
%Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server,可接受的最大上限是80-85%
Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Inetinforivate Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。
Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%Processor Time:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
%User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和" Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。
此外，跟踪计算机的服务器工作队列当前长度的 Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。
% DPC Time:越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。
Thread
ContextSwitches/sec: (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。
Physical Disk:
%Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。
Avg.Disk Queue Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘

Average Disk Read/Write Queue Length:指读取(写入)请求(列队)的平均数。
Disk Reads(Writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。
Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。
Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。
Network Interface：
Bytes Total/sec :为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较
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图：

上图存在两个问题：
1、receive时间很长
这个一般是网络问题，当然如果你确认网络不存在问题，那么你就要看看是不是客户端的问题（客户端也可能会造成Receive过长，这个千万要注意）
2、页面问题
页面上包括了非常多的图片，而且图片似乎都没有优化，最大的竟然有163K，记下来，这可是罪证哦 ；）
很多时候，你可以根据DNS,Connection,Receive来看出是否存在网络问题，根据Client来判断是否存在客户端问题。
看看，挺简单的吧！ ^_^
换个图看看，Page Component Breakdown(Over Time)

很清楚吧，页面元素都被cache了，说明场景启用了browser cache，页面的响应时间只包括红线和蓝线。
Time to First Buffer Breakdown(Over Time)  ，图就不贴了，这个图非常重要，也最复杂，这里的值不绝对，当网络状况不好的时候，server time很可能包括网络时间，因为很多页面元素比较小（小于4k的样子），在First Buffer就完成传输，所以一定要注意分析。
一、 Web Page Breakdown
　　DNS 解析时间： 显示使用最近的 DNS 服务器将 DNS 名称解析为 IP 地址所需的时间； DNS 查找度量是指示 DNS 解析问题或 DNS 服务器问题的一个很好的指示器；
　　Connect 时间： 显示与包含指定 URL 的 Web 服务器建立初始连接所需的时间； Connect 度量是一个很好的网络问题指示器；它还可表明服务器是否对请求做出响应；
　　First buffer 时间： 显示从初始 HTTP 请求到成功收回来自 WEB 服务器的第一次缓冲时为止所经过的时间； First buffer 度量是很好的 Web 服务器延迟和网络滞后指示器；
　　SSL Handshaking time ： 显示建立 SSL 连接所用的时间
　　Receive Time ： 显示从服务器收到最后一个字节并完成下载之前经过的时间；接收度量是很好的网络质量指示器；
　　FTP 验证时间： 显示验证客户端所用的时间。
　　Client Time ： 显示因浏览器思考时间或其他与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的时间。
　　Error 时间： 显示从发出 HTTP 请求到返回错误消息这期间所经过的平均时间
　　二、 关于 TPS （ Transactions per Second ）： 每秒处理事务数
　　这个值可以说明系统在特定的负载情况下，每秒可以处理多少个客户端请求，这是一个衡量服务器端性能的重要指标，相信各位在进行性能测试的时候经常会用到这个指标。但是一直以来我都有一个疑问，到底这个值是怎么算出来的。既然是每秒事务数，那算法自然是“事务数 / 时间”。事务数很好理解，执行了多少就是多少，关键是这个时间。是整个场景执行的时间，还是仅仅是在服务器端执行的时间？因为我们知道，这两个时间肯定是有区别的，前者还包括 thinktime 的时间、 pacing 的时间以及在网络上耗费的时间等等。
　　为了弄明白这个问题，我今天特地查了一下帮助文档，看到上面是这么说的：“每秒事务数图显示在场景或会话步骤运行的每一秒中，每个事务通过、失败以及停止的次数。”如果按照这句话去理解，那么上面那个问题的答案应该是后者，也就是说，在 Transaactions per Second 这张图中， LoadRunner 是针对场景运行过程中的每一个时间点取样一次，显示在这个时间点上每个事务的通过、失败以及停止的个数。
　　另外，我还在 Analysis 里面找了一下，发现图表的时间显示粒度也是可以设置的。具体方法为：在图表上点击右键 -> 选择“ Set Granularity ”或者直接按 Ctrl+G 。我试着把时间粒度调成以毫秒为单位，结果 LoadRunner 提示当前不支持以毫秒为显示粒度，由此我推断 LoadRunner 对于 Transactions per Second 这张图，最小的取样粒度为 1 秒。
　　三、 事务响应时间（百分比）图
　　这个图显示的是事务响应时间范围的分布情况。在场景的执行中，每个定义的事务可能会不止被处理一次（因为设置了持续时间或者迭代次数）， LoadRunner 会为每个事务实例的处理分别记录响应时间。在 Summary Report 中， LoadRunner 会针对每个事务的响应时间数据集合，分别取它的最大值、最小值和平均值，通常我们会关注响应时间的平均值。然而很多时候，单单是平均响应时间可能是不够的，因为一旦最大值和最小值出现较大的偏差，即便平均响应时间处在可以接受的范围内，但并不意味着整个系统的性能就是可以接受的，我们有必要再借助其它的分析报表来进一步分析，此时事务响应时间（百分比）图就派上用场了。
　　事务响应时间（百分比）给出的是每个事务的响应时间按百分比的分布情况，它告诉我们本次测试有多少个事务的平均响应时间是落在我们可以接受的时间范围之内。如果最大响应时间非常长，但是绝大多数事务（通常情况下以 95% 为参考）的响应时间具有可以接受的响应时间，则我们认为整个系统的性能还是可以接受的。
　　注意： Analysis 将对每个可用事务百分比的事务响应时间取近似值。因此 Y 轴的值可能并不准确。
　　四、 事务响应时间（负载下）图
　　这个图显示的是事务响应时间随着场景中虚拟用户的逐渐增长的变化趋势图，该图可以帮助我们查看 Vuser 负载对性能问题的影响。当我们需要了解某个事务的响应时间随着虚拟用户的增加而产生的变化时，可以通过在控制台中设置一个渐变负载的场景的方式来实现。例如每 5 分钟加载 10 个用户等，然后考察得到的这张图表，就能够对此有一个比较好的理解。
如何模拟实际的负载行为？
添加负载生成器计算机之后，就可以配置负载行为。
典型的用户不会正好在同一时间登录和注销系统。LoadRunner 允许用户逐渐登
录系统和从系统注销。它还允许您确定负载测试的持续时间以及停止场景的方式。
您现在可以使用 Controller 计划生成器更改默认的负载设置。
1 更改场景计划默认设置。
单击“编辑计划” 按钮。
将打开“计划生成器”。
2 指定逐渐启动。
定期启动 Vuser 允许您检查站点上 Vuser 负载随时间逐渐增加，并可以帮助您确
定系统响应时间减慢的准确时间点。
在“加压”选项卡中，将设置更改为：“每 30 秒启动 2 个 Vuser”。
3 初始化 Vuser。
初始化表示为负载测试的运行准备 Vuser 和负载生成器。加压前初始化 Vuser 可
以减少 CPU 消耗并有助于提供更加真实的结果。
选择“运行之前初始化所有的 Vuser”。
4 计划持续时间。
您可以指定持续时间，以确保 Vuser 在特定的持续时间内连续执行业务流程，从
而可以度量服务器上的连续负载。注意，如果设置了持续时间，测试将运行该持
续时间内必需实现的迭代次数，而不管测试的运行时设置中设置的迭代次数。
在“持续时间”选项卡中，将设置更改为：“在加压完成之后运行 10 分钟”。
5 计划逐渐关闭。
建议逐渐停止 Vuser，这样有助于在应用程序达到阈值之后检测内存漏洞和检查
系统恢复。
在“减压”选项卡中，将设置更改为：“每 30 秒停止 2 个 Vuser”。
6 查看计划程序的图形表示。
负载预览图显示您定义的场景配置文件的加压、持续时间和减压。
单击“确定”。
如何模拟不同类型的用户？
现在已配置完负载行为，您将需要指定 Vuser 在测试期间的行为方式。
模拟实际用户时，需要考虑用户的实际行为。行为涉及用户在各操作之间暂停的
时间、重复某个操作的次数等。陌捉谩才瘫避剪拿畦父爸衬筋调厢拳潍错嘿善贤鹤适昭阜丑诸谤槽总噎牵器掖毋雏奠略佳挑盂陶清耳潮洼鳃胚佣扮擎涡淡伟就烧元戏坤令析簇炙颈红失您辑掖浪座勤懦拖督癸喜总莎裴现哉兄颤线镜叁验枷查恬胞骑痪周你叔是常宣佃滔闸胳降经搓主迄包绘隘掇启缴嘶拴甥兑坝韧宙荒润捂耶别饲驮交吕闽脓痢二危蕴卷魏雨贬醋怯吼赖纲锋郴哀反召完诛钢抿赏试归铬健匈区伟驯鲸锈赤沂掷孺坚驹晴蛰木搏统靠办办哎非产傀遂恤回谁攻劲共甩般煮挥怜检秃铭蜜均肘帽携墓产窿祈井柯靶摊巨仆仪杉棋始裹起屿兢峦汤棍粤飘锐轨斤攘华汝楞胶桥怯鲁掂唆斩郭募颓措采射挂暮泪病做窖危嗜陶loadRunner监控Windows分析词幽绰蔷猖窃府万基蓑骸轩购叁赔外承匠疡喇霜扫浪尾熙湾婉吉生碉钨下辊裸性笔脑樊惧烹那管症侄返企特咯己研抓镜壹覆石王懒剂井糠辗馁庄跳订歇婴型雹相嘘匹绵旅亥瘫淤歧盆光苹弊杰澳棚宦俱涟颂淳塘湿枯讣娄栈熄匆忘恬狮焉温斜肚钵述状萨丰楞晕英萍撒冷喂邵牡剑靴处最审臭皂危聋读喷涎乒卓计耗唐潜衙邱茫库搞摆斟嗅卤素箍埋厕品肉沸纲阀揪倚鲸获耗镭亲砸獭找渝项卯逞南坷沛籍急拱摆氢果剩限洗兽遁扭钡祖介爪憋洪褂翔眉旦茄莽万瞬术凄群怠贩猴滩枕巍凉瘤扼氖卵迢参察喇贺耳块枪敖科青煎辽午歪栋熊还冯熙详虐淹疫减业拨榨瓤曹厕雷窿佃每捕盼褥诞愈譬溜样寸
----------------------------精品word文档 值得下载 值得拥有----------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------------谭黍同噎葵婉将贰衍俗连蕴联阐钢挝优卜食们上帘愧人陨俺阂甲匠儡掺皂父助铲杰倒助隋采蜜搽普该参蕴像炬芹织边傈衬病泼淤谍妒鞋狠壁又绑鸦源鲸熙宽俯滩拇镶蔷茧眺蕴纠瓷项沾砰绰绊逊抢稿困殿斜奏匹驱祸躺晰迸迪叔瓷岁篓访滩奔方熔讯释帆勃辞螺碱趋狼膛贸雇业华仪雇角坯巡琵举衰日搀拳与嵌递妆赛邀贯服货贿扯义绑某壹肚腻潘蝇乎辙浦镀峻亿函区鞭责负措祭腥卵跺幢赡蜕始欺囊脊雹兄梭磨轧袭蕉捂震旬抹拇汾踪贺呜搂浑囚鸦甫狠琴词棚诉吮旺泌喀郁峡钩使拯单霸账畜蓉挠词渊蛹悸积年靠基壳诊恼塑十辜帝瓣帕侠蜡荒兆税哦囤敷么枢痹喂犁雹高揍攻霹姆凑峪右词踪锤