<本文属原创,如需转载请与本人联系>
第十章 情境分析
在前面课程中我们已经学到了如何设计、控制、执行一个情境。一旦服务器上存在负载,你就想要分析执行情况,你就需要查明问题所在,消除问题来提高系统的性能。
在你的分析会话中产生的图表和报表可以提供关于情境德重要信息。通过这些图表和报告,你可以很容易德查明你的系统的瓶颈,以及确定出为了提高系统的性能你需要做哪些改进。
本课我们将会设计如下话题:
Ø 分析会话如何工作?
Ø 如何开始分析会话?
Ø 浏览分析窗口
Ø 是否达到目标?
Ø 服务器性能是否完好?
Ø 如何查明资源问题?
Ø 在情境执行中我能收集到其他的什么信息?
Ø 如何公布我的发现?
Ø 结论
分析会话如何工作?
分析会话的目的是找到你系统性能的缺陷,并且定位缺陷产生的原因
1. 是否达到了预期的目标?在存在负载的情况下,终端用户的事务处理响应时间是多少?这个事务处理的平均响应时间是多少?
2. 哪里导致系统性能下降?网络和服务器的响应时间是多少?
3. 能否找到事务处理时间和监视器备份间的关系矩阵?
在接下来的部分,你将会学习如何打开LoadRunner的分析功能,建立、查看图表和报告来帮助你找到性能问题,定位原因。
如何开始分析会话?
1. 打开Mercury LoadRunner。
选择Start > Programs > Mercury LoadRunner > LoadRunner. 打开
Mercury LoadRunner Launcher窗口。
2. 打开LoadRunner Analysis分析器
在Load Testing 标签中, 单击Analyze Load Tests. 打开LoadRunner Analysis
3. 打开分析会话文件
本部分目标和有趣的,我们这里执行的情境和上一节中的很像。然后这次涉及到到虚拟用户不是10个而是70个。打开这个情境结果产生的Analysis session(分析会话)。
在分析窗口中,选择File>Open, 已经存在的分析会话窗口被打开了。
在<LoadRunner Installation>/Tutorial 目录下, 选择analysis_session,并单击Open.
![](http://blogimg.chinaunix.net/blog/upfile/071011172535.jpg)
在Analysis窗口中打开了分析会话文件。
浏览分析窗口
Analysis 窗口包括三个主要部分:
Ø 图表树
Ø 图标视图区
Ø 图例
![](http://blogimg.chinaunix.net/blog/upfile/071011172637.jpg)
Graph Tree: 图表树在面板的左侧,显示处待分析的图表。在这里也可以显示出分析器没有打开的图表,或者删除你不想要再看的图表。
Graph Viewing Area: 图表视图区,在面板的右侧,分析器显示出图表,当你打开一个session会话时,默认的在这个区域里会显示这个分析的概述报告。
Graph Legend: 图例,在面板的下侧,你可以看到选定的图表的有关数据。
在图表视图区域中查看分析概述报告。
![](http://blogimg.chinaunix.net/blog/upfile/071011172724.jpg)
在报告的Statistics Summary部分,你可以看到在这个测试过程中最多有70个用户在执行,其他的统计信息,入总的/平均吞吐量,总的/平均点击率也显示在这里。
是否达到目标?
分析会话的目的中,最终要而且也最有趣的部分是报告,然而分析的目的确实事务概述:Transaction Summary
在事务概述中列出了每个事务行为的概述。
查看每个事务的响应时间。90 Percent这一栏显示了某些执行了90%的事务。你可以看到在测试过程中check_itinerary这个事务在65.744秒中执行了90%,这个是这个事务的平均响应时间32.826的两倍,这意味着当前执行的事务的大多数部分具有很高的响应时间。
我们也可以发现这个事务失败了28次。
1. 打开平均事务响应时间图表
在Transaction Name栏中,单击Check_itinerary 事务。
在图表视图区域中打开Average Transaction Response Time graph,在图表中Check_itineray transaction 显示为高亮色。
![](http://blogimg.chinaunix.net/blog/upfile/071011172856.jpg)
图表中的点代表在情境执行过程中某个特定时间的事务的平均响应时间。将光标停留在图表中的某一点上,会显示出一个黄色的框框,显示出那点所对应的信息。
![](http://blogimg.chinaunix.net/blog/upfile/071011172948.jpg)
2. 结果分析
注意,check_itinerary事务平均响应时间的波动,在情境执行中其峰值为75.067秒。
在一个性能良好的服务器上,事务应当的响应时间应该在一个平均水平上下浮动。在图表的下部,注意看logon,logoff, book_filight, 和 search_flight这些事务遵循一个稳定的平均时间浮动。
服务器性能是否完好?
在前面的部分你已经发现你的服务器的性能并不稳定。你将需要分析70个虚拟用户同时执行时对系统性能的影响。
1. 研究虚拟用户的行为
在图表树中单击Running Vusers
![](http://blogimg.chinaunix.net/blog/upfile/071011173035.jpg)
在图表的视图区域中打开了Running Vusers图表。你可以看到从情境执行开始虚拟用户的逐级递增。然后,在3分钟后,70个用户开始同时执行,然后用户数开始递减。
2. 对图表进行过滤,你可以看到所有的虚拟用户同时执行时的切片。
当你对图表过滤时,图表的数据部分开始变窄,因此只有你指定的数据才会显示出来,其他部分将被依隐藏。
右单击该图表,选择Set Filter/Group By,或者在工具栏中单击Set Filter/Group By 图标。
在Filter Condition 部分,选择Scenario Elapsed Time行中的Values栏。单击向下箭头,选择时间范围为1:30minutes 到3:45minutes,单击OK。
在Graph Settings对话框中单击OK。
这时执行的虚拟用户图表中将只会显示情境在1:30minutes到3:45minutes中虚拟用户执行的情况,其他的虚拟用户已经被过滤掉了。
![](http://blogimg.chinaunix.net/blog/upfile/071011173200.jpg)
注意:要想清楚这个过滤,需要右单击图表,选择Clear Filter/Group By,或者在工具栏中单击Clear Filter/Group By
3. 关联对比Running Vusers和Average Transaction的响应时间
你可以将两个图表连到一起,来在一个图表中查看另一个图表的数据,这就是两个图表的关联。
例如:你可以将Running Vusers图表和Average Transaction Response Time图表关联起来,从而发现虚拟用户数目增加对事务的平均响应时间的影响。
右单击Running Vuser图表,选择Merge Graphs
在Select graph to merge with 列表中,选择Average Tracnsaction Response Time
在Select Type of merge 区域中选择Correalate, 单击OK
现在在图表视图区域中Running Vusers图表和Average Transaction Response Time 图表已经变成了一个图表Running Vuser-Average Transaction Response Time 图表
![](http://blogimg.chinaunix.net/blog/upfile/071011173359.jpg)
4. 分析关联图表
在这个图表中,你可以发现随着虚拟用户的增加,check_itineray transaction 的平均响应时间在逐渐增加。换句话说,平均想以你国时间随在负载的增加也在平稳的增加。
在右64个虚拟用户时,平均响应时间剧增。我们说这个测试破坏了服务器。然后在倒倒64个虚拟用户开始同时执行时响应时间开始明显的下降。
保存一个模板
到现在为止,你已经过滤了一个图表,并且关联了两个图表。在下一次对情境分析时,你可能先看到具有相同的过滤条件和混合条件的图表。你可以将你合并过的图表和过滤过的图表保存成模板,在下一此分析中应用他们。
如何保存模板:
1. 在Tools菜单中,选择Templates > Save as Template...
2. 给模板起个适当的名字
3. 清除Automatically apply this template to a new session选项
4. 单击OK
下次当你打开新的分析会话,想要使用已经保存过的模板时:
1. 在Tools菜单中,选择:Templates > Apply/Edit Template.
2. 在列表中选择你的模板,单击Apply Template.
如何查明资源问题?
到现在为止,当增加服务器的负载后,对check_itinerary 事务的平均响应时间有负面影响。
你可以进一步查看Check_itineray 事务,看究竟是什么系统资源对事务的性能产生了负面的影响。
LoadRunner分析的唯一性,自动关联工具可以将所有的包含对check_itinerary事务的响应时间有影响的数据合并到一起,从而查出在出现问题的时候究竟发生了什么问题。
1. 在图表树中,选择Average Transaction Response Time 图表。
![](http://blogimg.chinaunix.net/blog/upfile/071011173449.jpg)
查看check_itinerary 事务,重点是在过去的1到4分钟间的切片。在接近3分钟后,平均响应时间立即增加达到峰值。
2. 对Average Transaction Response Time图表进行过滤,使之只能显示check_itinerary 事务。
右单击该图表,选择Set Filter/Group by.
在Transaction Name value 框中,选择check_itinerary.
单击OK.
过滤后的图表将其他的事务隐藏起来,只显示check_itinerary transaction
![](http://blogimg.chinaunix.net/blog/upfile/071011173606.jpg)
3. 自动关联图表
右单击该图表,选择Auto Correlate.
![](http://blogimg.chinaunix.net/blog/upfile/071011173653.jpg)
在Auto Correlate 对话框中,确保measurement to correlate是Check_itinerary, 将时间范围设置为:1:20到3:40分钟,或者直接输入时间,或者在Elapsed Scenario Time轴上直接拖拽红色和蓝色的柱。
单击OK
在图表的视图区域中会显示出自动关联图表,check_itinerary事务显示为高亮。
![](http://blogimg.chinaunix.net/blog/upfile/071011173740.jpg)
自动关联图表名默认为:Auto CorrelatedGraph [number].
4. 图表重命名
在图表树中,右单击Auto Correlated Graph [number]图表,选择Rename Graph.,图标名便可以编辑。
输入Auto Correlated - check_itinerary,单击ENTER,或者单击分析窗口的其他部位。
5. 分析自动关联图表
查看图表中的图例
![](http://blogimg.chinaunix.net/blog/upfile/071011173832.jpg)
在Measurement栏中,你可以看到Private Bytes 和Pool Nonpaged Bytes,这两个都是内存相关联的指标,与check_itinerary 事务的关联程度超过了70%。这意味着在某些内部指定的时间内这些因素和check_itinerary事务的行为关联紧密。
我们可以推断出当check_itinerary的响应时间达到峰值时,系统内存严重不足。
在情境执行中我能收集到其他的什么信息?
除了在分析会话开始时提到的图表树外,你可以查看其他的图表来获得情境执行时的其他的信息。
1. 显示一个新的图表
在工具栏中单击Add New Graph图标,或者在图表树中单击New Graph
在Open a New Graph dialog对话框中,列出了包含数据并可以显示出来的图表。
![](http://blogimg.chinaunix.net/blog/upfile/071011174006.jpg)
Ø Vuser:图表显示出虚拟用户的信息和他们的状态。
Ø Error:图表显示错误统计内容。
Ø Transaction:图表显示出事务的相关数据和他们的响应时间。
Ø Web Resource:图表显示点击率,吞吐量,以及连接数据量。
Ø Web Page Breakdown:图表显示在你脚本中每个被监视的页面的数据。
Ø System Resource:图表显示系统资源使用数据。
在Open a New Graph dialog对话框中,单击category旁边的“+”可以将其扩展开。
选择一个图表,单击Open Graph对话框。
单击Close关闭打开的Open a New Graph dialog对话框
现在可以打开其他的图表,从而可以更好的理解你的情境。
如何公布我的发现?
你可以在分析会话中以HTML格式或者word格式发布这些发现。这个报告会使用一个已经设计好了的模板,包括注释、图形的比例和数据。
HTML格式报告:
HTML格式的报告可以在任何浏览器中打开。
建立一个HTML格式的报告:
1. 在Report菜单中,选择HTML Report
2. 为报告指定一个文件名,以及要保存的路径,单击Save
分析创建这个报告,并且可以在你的浏览器中显示这个报告。注意HTML格式报告的布局和你分析会话的布局很像,你可以单击左侧的面板观察各种图表。每个图表的描述显示在页面的下方。
Word格式报告:
你可以将分析会话提交为word报告。Word形式的报告比HTML格式报告更全面,其中包含有情境的普通信息,评测描述等选项。你也可以在报告中填加公司的名字、图表,做着的详细信息。
和其他的word文档很像,这个报告是可以编辑的,你可以进一步增加评论以及报告建立后的新的发现。
建立一个word格式的报告
1. 在Reports菜单中,选择Microsoft Word Report…
打开Microsoft Word Report对话框
2. 单击Format标签
Ø 输入报告名字
Ø 输入作者名字,职位,公司的名字
Ø 默认的,这个报告包含有标题页,内容表,图表明细及描述和评测描述
Ø 在Company logo处,选择Include company logo, 单击Browse找到图表的路径,注意格式为.bmp.
Ø 输入路径保存报告
3. 单击Primary Content标签
Ø 选择你在报告中想要包含的情境和分析会话。默认的,除了Sever Performance以外的所有部分都会包含在列表中,被选中。
选择Sever Performance
Ø 单击Edit,打开Executive Summary对话框,在这里输入你的目的和结论。
在Objectives框中,输入“The objectives of the test scenario were to...”.在Conclusions框中输入“The conclusions I reached are as follows:”
单击OK关闭Executive Summary对话框。
4. 单击Additional Graphs标签
Ø 指定在报告中你想要看到的图表。默认情况下,会话中的所有图表都会被列出来,并被选中,图表的注释也会包含在报告中
Ø 要想获得更多的信息,你可以增加在会话中没有打开的图表。
单击Add按钮,打开Open a New Graph对话框,扩展系统资源范围,选择Windows Resource图表。单击Add Graph,单击Close, 关闭Open a New Graph对话框。Windows资源图表显示在图表列中,将会被包含在报告中。
Ø 你可以在报告中调整图表的显示顺序
单击 Average Transaction Response Time选择这个图表。
单击Up按钮知道图表显示在Running Vusers的下方
在报告中,Average Transaction Response Time图表将会显示在Running Vusers图表的下侧。
5. 在Microsoft Word Report对话框中,单击OK
数据被收集起来了,同时建立了一个word格式的报告,并且在word文档中已经打开了这个报告。
除了在你的分析会话中产生的图表以外,报告中还包含目的和结论,以及你选择了的其他的部分和图表。
结论
在这节中你学到了分析一个执行完的情境的基础知识,并且发布了你的结果报告。
同时学到了通过研究各种图表可以定位系统性能瓶颈,也可以通过配置关联图表来定位由于负载过多,系统资源瓶颈导致的问题。