《性能测试进阶指南：Loadrunner实战91_第5章 数据收集分析.docx》由会员分享，可在线阅读，更多相关《性能测试进阶指南：Loadrunner实战91_第5章 数据收集分析.docx（49页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、目录第5章 数据收集分析Analysis25.1 新建Analysis分析25.2 Analysis Summary25.2.1 Analysis Summary(场景的摘要)35.2.2 Statistics Summary(场景状态的统计说明)35.2.3 5Worst Transaction(SLA失败事务)45.2.4 Scenario Behavior Over Time(场景行为综述)55.2.5 Transaction Summary(事务摘要)55.2.6 Service Level Agreement Legend(SLA图标说明)75.2.7 HTTP Responses
2、Summary(HTTP响应摘要)75.3 Graphs(数据图)85.3 .1 Vusers(虚拟用户状态)105.3.2 Errors(错误统计)115.3.3 Transactions(事务)115.3.4 WebResources(网页资源信息)155.3.5 Web Page Diagnostics(网页分析)175.3.6 Network Monitor(网络监控)225.3.7 Resources(资源监控)235.4 图设置与操作345.4.1 Merge Graphs (合并图)345.4.2 Auto Correlate(自动定位瓶颈)375.5 Transaction R
3、eport(事务报告)405.6 SLA Report(系统阈值监控报告)425.7 External Monitor(外部监控数据导入)435.8 Cross with result(跨脚本横向比较)455.9 生成测试报告465.9.1 创建HTML报告465.9.2 创建Word报告475.9.3 创建水晶报表47小结49第5章 数据收集分析Analysis通过场景完成负载后，我们完成了性能测试的执行过程，接着就是通过负载的结果来发现和定位性能瓶颈。在这里Analysis就好比一个数据分析中心或数据仓库，它将场景运行中所能得到的数据都整合在一起，能够对测试结果数据进行整理，并提供了一些方
4、法可以进一步对结果数据进行分析，从而找出系统的性能指标和可能的瓶颈，最终生成报告。可以把Analysis看作一个股票分析软件，将股票的数据收集分析后生成K线图，而具体说明了什么，还要依赖于分析者自身。使用Analysis进行性能测试结果的分析流程如图5.1所示。图5.1 Analysis结果分析流程5.1 新建Analysis分析导入场景数据生成Analysis报告的方式有以下三种：1 当场景运行结束后在场景直接运行Results菜单下的Analyze Results命令进入Analysis。2在Analysis中打开新建菜单，然后进入场景运行结束后的场景结果res目录，接着Analysis会
5、对整个场景数据进行整理，给出简明报告及相关图表。3在场景结果目录中直接双击Mercury LoadRunner Result(.lrr)文件。5.2 Analysis Summary当Analysis导入场景数据后，首先映入眼帘的是统计表格Analysis Summary场景摘要，提供了对整个场景数据的简单报告。下面介绍一下该报告的各个组成部分。5.2.1 Analysis Summary(场景的摘要)这里给出了场景的摘要(Analysis Summary)，包括以下内容：Period：场景运行的起止时间Scenario Name：场景名称Resultsin Session：场景运行的结果目录
6、Duration：场景运行的时间通过场景摘要可以了解场景执行的基础信息。5.2.2 Statistics Summary(场景状态的统计说明)场景状态的统计说明(Statistics Summary)包含以下内容：Maximum Running Vusers：场景最大用户数Total Throughput(bytes)：总带宽流量Average Throughput(bytes/second)：平均每秒带宽流量Total Hits：总点击数Average Hits per Second：平均每秒点击数单击View HTTP Responses Summary选项可以切换到报告的最下端查看HTT
7、P请求的统计。在每项数据标题和数据中，还会看到一个小的球形图标囊，单击后会进入SLA分析报告。5.2.3 5Worst Transaction(SLA失败事务)这里列出了对5大失败事务的统计，只有当在Controller或Analysis中定义了SLA status determined at time intervals over a timeline监控时才会出现该报告。Transaction Name(事务名)。Failure Ratio(exceeded time/transaction duration)失败率(超标次数/事务持续时间)。该值反映了在所有事务中有百分之多少的事务是无法
8、达到SLA基准值。Failure Value(response time/SLA)失败率(响应时间/SLA)。该值反映了在整个场景运行下，SLA的定义标准值与实际事务值超标的平均百分比，也就是说平均算下来真实的响应时间和定义的阈值误差百分比。通过这行报告，我们可以清晰地了解该事务有多少是无法达到SLA标准的，以及无法达到标准的事务与SLA的误差范围是多少。单击事务名前的加号还能列出该事务在SLA定义的持续时间下平均误差比例和最大误差比例。Analysis会根据SLA中的定义分析事务的通过率，在这个场景结果中，所有的事务响应时间都在SLA监控值以外，所以结果为Infinity全部超标。分析的失败
9、事务数可以在Tools菜单下Options的General标签中进行设置，默认为5个事务，如图52所示。图52 SummaryReport设置5.2.4 Scenario Behavior Over Time(场景行为综述)这里列出了在场景中定义的事务在各个时间点上的SLA情况，背景中的x表示在这个时间点上事务没有达到SLA的指标。而上面的Application Under Test Errors显示了在每个时间段上的错误数目。5.2.5 Transaction Summary(事务摘要) 这里首先给出的是场景中所有事务的情况说明：TotalPassed(事务的总通过数)TotalFailed
10、(事务的总失败数)TotalStopped(事务的总停止数)Average Response Time是一个链接，可以打开事务平均响应时间图表。下面给出每个具体事务的情况列表，可以看到以下数据项：Transaction Name(事务名)SLA Status(SLA状态)：在SLA的指标测试中最终结果是通过还是失败Minimum(事务最小时间)Average(事务平均时间)Maximum(事务最大时间)Std.Deviation(标准方差)标准方差，这个数据是描述采样数据离散状态很重要的指标，它又分为以下两种：1给定样本标准方差，它是估算给定样本而不是整个样本的标准方差(也就是样本中的一部分)
11、，计算公式如下：其中X代表平均值，n代表取样个数。n-1是统计学上的常用做法，主要考虑到采样量越大，越能反映真实的情况。2总体样本标准方差，它是估算整个采样样本的标准方差(注意是整个采样数据而不是部分)，计算公式如下：当采样数据足够大的时候，上述两种计算方式得出的偏差相差很小。标准方差相对于平均值越大，说明数据越离散，则分布状态相对于平均值波动很大；标准方差相对于平均值越小，说明数据分布越集中，曲线也越平稳。在采样值服从正态分布的条件下通过上面的指标结合平均值、最大值、最小值，可以比较清楚地知道采样数据的分布状态及其是否有较大的波动。90Percent(用户感受百分比)这个值说明的采样数据中有
12、90的数据比它小，有10的数据比它大，举例如下：假设有一组数据(1、3、4、6、5、7、8、2、9、10)，从小到大排序之后为(1、2、3、4、5、6、7、8、9、10)，在这10个数字中第九大的数字是9，所以90 Percent的结果就是9。它的主要作用就是来了解在某个响应时间内有百分之多少的用户。当然这个90是可调整的，在Analysis中通过View菜单中SummaryFilter下的Transaction Percentile选项来调整。Pass(事务通过数)Fail(事务失败数)Stop(事务停止数)5.2.6 Service Level Agreement Legend(SLA图标
13、说明) 图标为灰色带减号的为No Data，说明在SLA中未对这个数据项进行监控，没有数据；图标为红色带叉的为Fail，说明在SLA中定义了该项的数据监控，但该数据未能达到期望的阈值；图片为绿色带钩的为Pass，说明在SLA中定义了该项的数据监控，该数据达到了的期望阈值。5.2.7 HTTP Responses Summary(HTTP响应摘要)这里给出了服务器返回的状态。服务器返回HTTP请求状态(HTTP Responses，具体的服务器返回状态码见附录A)HTTP请求返回次数(Total)每秒请求数(Per second)通过Analysis Summary可以对整个性能测试的结果有一个
14、直观的介绍，特别是通过SLA的数据可以直观地了解在整个负载中系统的性能指标是否满足阈值，除此以外设置的事务响应时间数据也会显示。Analysis保存后会生成Mercury LoadRunner Analysis Session(lra)文件。通过File菜单下的Session Information功能可以了解该Session文件的属性，而File菜单下的View Scenario RunTime Settings功能可以查看该报告场景的运行设置。当粗略了解了整个场景的情况后，根据场景执行前的目标，可以对整个系统的性能有一定的了解，接着需要对关心的数据进行进一步的了解和分析。5.3 Graph
15、s(数据图)在场景运行时可以看到一些图，这些图将场景中的数据转化为折线图，方便我们了解当前该数据的状态。在默认情况下，Analysis会自动打开如图53所示的几张图。这是系统最基本的几个图，这些图反映了在不同时间段相关计数器的数据变化情况，可以通过在Graphs上右键菜单中的Add New Graphs命令完成添加图的操作，添加后弹出Graphs管理器，如图5.4所示。在Open a NewGraph窗口中，可以得到所有能添加的计数器图形，勾选左下角的Display only graphs containing data选项可以隐藏没有数据的计数器，有数据的计数器则会以蓝色显示在左侧区域。而选
16、中具体的图，在右侧的Graph Description中会有更加详细的介绍。在Graph Properties中还可以对生成的图表进行一定的属性设置，例如生成的图是使用整个场景的时间还是其中的某一部分时间。 图53默认情况下系统打开的Graphs图54数据图管理器对于任意一张图，都可以在右侧看到有2个功能：User Notes和Raw Data。UserNotes提供对某张图进行文字描述的功能；Raw Data是将生成该图的数据列出。在RawData中单击Click to retrieve raw data，会弹出Raw Data窗口，设置场景持续的时间，确认后可以得到该时间段内组成该图的所有
17、数据，如图55所示。图5.5 RawData数据表这里可以将数据另存为Excel文件，再通过第三方工具进行分析。例如将导出的场景数据使用SPSS工具进行进一步的数学分析。在图的下方，Legend窗口会显示图中对象说明信息以及相关数据，如图56所示。通过对显示对象的一些设置，可以得到更好的显示效果。在Legend窗口中单击鼠标右键，弹出菜单如图57所示。图56Legend图中对象数据说明图57Legend设置选项菜单可以通过Show/Hide/Show only selected/Show all命令设置所需要选的项目，也可以通过Configure measurements/Show measu
18、rement description命令设置线条的颜色及显示方式。Animate selected line选项可以在切换线条时获得更加明显的动画效果，Auto Correlate提供了对所选对象的自动关联操作(参考542节)，而在Configure columns中可以设置在Legend中显示哪些属性名。每张图都代表了场景运行中监控到的数据变化趋势，所以看懂每一张图的含义是性能分析的第一步，接着我们来介绍一些常见图的含义。5.3 .1 Vusers(虚拟用户状态)Vusers用户状态计数器组提供了产生负载的虚拟用户运行状态的相关信息，可以帮助我们了解负载生成的过程。Running Vuser
19、s(负载过程中的虚拟用户运行情况)该图可以反映系统形成负载的过程，随着时间的推移，虚拟用户数是如何变化的。在图58中可以看到用户在9分钟左右到达了负载峰值50个虚拟用户，负载的生成是大约每分钟增加5个用户，峰值负载持续1分30秒。图5.8 Running VusersRendezvous(负载过程中集合点下的虚拟用户数)当场景中设置了集合点后会出现这张图，该图反映了随着时间的推移各个时间点上并发用户的数目，方便我们了解并发用户数的变化情况。在图59中可以看到刚开始的7分钟内，负载的并发用户都是1个，而后面变化为2个用户并发。图5.9 Rendezvous5.3.2 Errors(错误统计)当场
20、景在运行中出现错误时，错误信息将会被保存在该计数器组中，通过Error信息可以了解错误产生的时间和错误的类型，帮助我们定位产生错误的原因。Errors per Second(每秒错误数)通过每秒错误数可以了解在每个时间点上错误产生的数目，该数据越小越好。通过这个图可以了解错误随负载的变化情况，定位何时系统在负载下开始不稳定甚至出错，配合系统日志可以定位产生错误的原因。在图510中可以看到场景在37秒的时候出现了一次错误。图5.10 Errors per Second5.3.3 Transactions(事务)这里给出了所有和事务相关的数据统计，方便了解被测系统业务处理的响应时间和吞吐量，在39
21、节中介绍了系统事务默认有3种状态PASS、FAIL、STOP，如果是手工事务那么状态会有PASS和FAIL两种。Average Transaction Response Time(平均事务响应时间)这是我们比较关心的数据之一，反映随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。如果和前面的用户负载生成图合并在一起看，就可以发现用户负载增加对系统事务响应时间的影响规律。在图511中可以看到响应时间是如何增长的，随着时间的推移响应时间逐渐变长，并且在不到8分钟的时候突然出现响应时间大幅下降的情况。图5。11 Average Transaction Response Time另外事
22、务的响应时间也不应该超过用户的最大接受范围，否则会出现系统响应过慢的问题。Transactions per Second(每秒事务数)另一个关键数据是TPS吞吐量，该数据反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。在图512中上面的线是通过的事务，下面的线是失败的事务，这里可以看到系统的TPS随着时间的变化逐渐变大，而在不到10分钟的时候系统每秒可以处理1.9个事务。这里的最高值并不一定代表系统的最大处理能力，TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。而在4分钟以后开始出现少量的失败事务。图5.12 Tran
23、sactions per SecondTransactionSummary(事务概要说明)该说明给出事务的Pass个数和Fail个数，了解负载的事务完成情况。通过的事务数越多，说明系统的处理能力越强；失败的事务越少，说明系统越可靠。在图513中可以看出，对于reg注册操作一共有613次操作成功，有6次失败。可以考虑结合前面的每秒错误数进一步分析为什么会出现6个注册错误，以及错误发生的时间和该时间产生错误的原因。图5.13 Transaction SummaryTransaction PerformanceS ummary(事务性能概要)这里会给出事务的平均时间、最大时间、最小时间柱状图，方便分
24、析事务响应时间的情况。在图5.14中可以看到reg这个事务最大时间为3.897s，最小时间为2.555s，平均时间为2.924s。柱状图的落差越小说明响应时间的波动较小，如果落差很大，那么说明系统不够稳定。图5.14 Transaction Performance SummaryTransaction Response Time Under Load(在用户负载下事务响应时间)这里给出了在负载用户增长的过程中响应时间的变化情况，其实这张图也是将Vusers和Average Transaction Response Time图做了一个Correlate Merge得到的，该图的线条越平稳，说明系
25、统越稳定。在图5.15中可以看出在负载逐渐增加到5个用户时，事务的响应时间基本没有变化。而用户增加到15个开始，随着用户负载的增加响应时间也有较大的波动。 图5.15 Transaction Response Time Under LoadTransaction Response Time(Percentile)(事务响应时间的百分比)这里给出的是不同百分比下的事务响应时间范围，通过这个图可以了解有多少比例的事务发生在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。在图5.16中可以看到60的事务是在3秒内。图5.16 Transaction Response Tim
26、e(Percentile)Transaction Response Time(Distribution)(每个时间段上的事务数)该图给出的是在每个时间段上的事务个数，响应时间较小的分类下的事务数越多越好。从图5.17中可以看到在所有的事务中，有391个事务的响应时间最接近2秒，而有222个事务的响应时间最接近3秒。图5.17 Transaction Response Time(Distribution)5.3.4 WebResources(网页资源信息)这里给出的是对于Web操作的一些基本信息，这些信息在服务器端也能获得。当Controller的RunTime Setting中Preferen
27、ces下的Generated Web performance graphs选项处于开启状态时，该图表才会出现。Hits per Second(每秒点击数)每秒点击数提供了当前负载中对系统所产生的点击量记录。每一次点击相当于对服务器发出了一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。在图5.18中可以看出随着时间的增加，每秒点击数在上升，最高达到78次s。图5.18 Hits per SecondThroughput(带宽使用)这里给出了在当前系统负载下所使用的带宽，该数据越小说明系统的带宽依赖越小，通过这个数据能确定是否出现了网络带宽的瓶颈(注意这里使用的单位是字节)。在图5.1
28、9中可以得到最高的带宽峰值是355000B，远远低于100Mb的局域网带宽上限，所以系统不存在带宽瓶颈。图5.19 ThroughputHTTP Responses per Second(每秒HTTP响应数)这里给出了每秒钟服务器返回各种状态的数目，该数值一般和每秒点击量相同。点击量是指客户端发出的请求数，而HTTP响应数是指服务器返回的响应数。如果服务器返回的响应数小于客户端发出的点击数，那么说明服务器无法应答超出负载的连接请求。在图5.20中可以看到最高峰时服务器每秒能返回接近75个HTTP 200 OK的状态。图5.20 HTTP responses per Second这个数据和前面的
29、每秒点击数吻合，说明服务器能够对每一个客户端请求进行应答。Connections Per Second(每秒连接数)这里会给出两种不同状态的连接数，即中断的连接和新建的连接，方便用户了解当前每秒对服务器产生连接的数量。在图5.21中可以看到随着时间的推移，系统的连接数逐步上升，最高达到每秒4个连接。图5.21 Connections Per Second同时的连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止上升时，说明系统的连接池已满，无法连接更多的用户，通常这个时候服务器会返回504错误。可以通过修改服务器的最大连接数来解决该问题。5.3.5 Web Page Diagnost
30、ics(网页分析)当在场景中打开Diagnostics菜单下的Web Page Diagnostics功能，就能得到网页分析组图。通过这个图，可以对事务的组成进行抽丝剥茧的分析，得到组成这个页面的每一个请求时间分析，进一步了解响应时间中有关网络和服务器处理时间的分配关系。通过这个功能，可以实现对网站的前端性能分析，明确系统响应时间较长是由服务器端(后端)处理能力不足还是客户端连接到服务器的网络(前端)消耗导致的。更多内容参考6.1.5节中的前端性能分析。Web Page Diagnostics(网页分析)添加该图先会得到整个场景运行后虚拟用户访问的Page列表，也就是所有页面下载时间列表。这里
31、对Discuz.Net论坛的注册用户事务进行分析。在图5.22中可以看到整个负载由3个页面请求组成，其中有一个请求始终在0.8秒以内，而另外2个请求时间较长并且有上升趋势。图5.22 Web Page Diagnostics然后通过Select Page to Break Down命令选择具体的Page来获得每个请求的相关详细信息。这里选择创建用户的“172.168x?createuser=1”请求进行分析。稍后可以在图5.23中看到创建用户响应时间的变化，随着时间的增长响应时间从2.6秒上升到了3.9秒，并且在7分30秒时大幅下滑，回到2.6秒左右。图5.23 Web Page Diagno
32、stics对用户注册页面细分在Diagnostics options选项中提供了以下4大块功能。Download Time(下载时间分析)这里可以得到组成页面的每个请求下载时间。在图5.24中可以看到创建用户的操作由4个请求组成，其中导致注册用户较慢的主要原因是注册完成后需要等待两秒钟再刷新至论坛首页，而非注册用户本身需要消耗的时间。首页刷新慢也只是因为Client(客户端)需要消耗较多时间，同时Receive(接收)的时间也有一定的影响。图5.24 Web Page Diagnostics Download TimeComponent(Over time)(各模块的时间变化)这里列出组成页面
33、的每个元素，以及随着时间的变化所带来的响应时间变化。通过这个功能可以分析响应时间变长是因为页面生成慢，还是因为图片资源下载慢。在图5.25中可以发现随着时间的增加，首页的处理时间(最上面的一根线)从0.5秒上升到了最大值16秒，而注册用户响应时间几乎没有上升。图5.25 Web Page Diagnostics Component(Over Time)Download Time(Over time)(模块下载时间)这里提供了针对每个组成页面元素的时间组成部分分析，方便确认该元素的处理时间组成部分。在图526中可以发现首页请求的下载时间主要消耗在Client上，而7分30秒之前Recevie所消
34、耗的时间在逐渐变长。图5.26 Web Page Diagnostics Download Time(Over Time)Time to First Buffer(Over time)(模块时间分类)这里会列出该元素所使用的时间分配比例，是受Network Time影响的多还是ServerTime影响的多。在图5.27中可以看出，对于首页刷新的响应时间来说，主要是NetworkTime网络上消耗的时间，而Server Time服务器端的处理是非常优秀的。ServerTime是指服务器对该页面的处理时间；Network Time是指网络上的时间开销。图5.27 WebPage Diagnosti
35、cs Time to First Buffer(Over time)通过这4个分析图，我们可以了解到对于事务的响应时间来说，服务器的处理时间并不是组成响应时间的主要部分，而网络问题通常会占用超过70的时间，通过Web Page Diagnostics可以准确分析响应时间，避免由于网络延迟或者带宽问题而影响对响应时间的分析和瓶颈定位。在LoadRunner的安装目录下找到LRAnalysis80.ini文件，在其中的WPB下添加SURLSize=255，另外还需要修改loader2.mdb文件，将其中Breakdown-map表中的EventName的属性长度从50修改为255，在以后场景运行结
36、果的报告中就可以显示最长为255字符的路径名称了。Page Download Time Breakdown(页面响应时间组成分析)这张图中显示了每个页面响应时间的组成分析，一个页面的响应时间一般由以下内容组成：Client Time客户端浏览器接收所需要使用的时间，可以不用考虑。Connections Time连接服务器所需要的时间，越小越好。DNS Resolution Time通过DNS服务器解析域名所需要的时间，解析受到DNS服务器的影响，越小越好。Error Time服务器返回错误响应时间，这个时间反映了服务器处理错误的速度，一般是Web服务器直接返回的，包含了网络时间和Web服务器返
37、回错误的时间，该时间越小越好。First Buffer Time连接到服务器，服务器返回第一个字节所需要的时间，反映了系统对于正常请求的处理时间开销，包含网络时间和服务器正常处理的时间，该时间越小越好。FTP Authentication Time FTP认证时间，这是进行FTP登录等操作所需要消耗的认证时间，越短越好。Receive Time接受数据的时间，这个时间反映了带宽的大小，带宽越大，下载时间越短。SSL Handshaking TimeSSL加密握手的时间。而Analysis在这里会分析得到页面请求的组成比例图，便于分析页面时间浪费在哪些过程中。在图5.28中可以看到各个页面请求的
38、响应时间组成情况，相对于172.168.0.200的首页请求，时间主要浪费在Client上。图5.28 Page Download Time BreakdownPage Download Time Breakdown(Over Time)(页面组成部分时间)这里提供了随着时间的变化所有请求的响应时间变化过程。这里会将整个负载过程中每个页面的每个时间组成部分都做成单独的时间线，以便分析在不同的时间点上组成该页面的各个请求时间是如何变化的。在图5.29中可以看到大多数页面的响应时间是比较稳定的，其中首页刷新变动较大。图529 Page Download Time Breakdown(Over Ti
39、me)首先找到变化最明显或者响应时间最高的页面，随后再针对这个页面进行进一步的分析了解时间偏长或者变化较快的原因。Time to First Buffer Breakdown(页面请求组成时间)这里提供了组成页面时间请求的比例说明(客户端时间/服务器时间)，通过这个图，我们可以直观地了解到整个页面的处理是在服务器端消耗的时间长，还是在客户端消耗的时间长，从而分析得到系统的性能问题是在前端还是在后端。在图5.30中可以看出对于整个负载来说，网络或客户端的时间开销占了绝大多数。Time to First Buffer Breakdown(Over Time)(基于时间的页面请求组成分析)和图530
40、不同的是，这里给出了在整个负载过程中，每一个请求的Server Time和Client Time随着时间变化的趋势，可以方便定位响应时间随着时间变化的原因到底是由于客户端变化导致的还是由于服务器端变化导致的。图530 Time to First Buffer Breakdown在图531中可以看到对于用户注册操作，网络上的时间变化比服务器上的时间变化要剧烈。图5.31 Time to First Buffer Breakdown(Over Time)5.3.6 Network Monitor(网络监控)如果在Controller中添加了Network Delay Time监控后会出现该数据图。
41、这个功能很好但并不是非常直观和方便，建议使用第三方专门的路由分析工具进行网络延迟和路径分析。Network Delay Time这里会给出从监控机至目标主机的平均网络延迟变化情况。在图532中可以看到网络延迟从240毫秒逐渐减少到26毫秒，最后上升到340毫秒。图532 Network Delay TimeNetwork Sub-Path Time这里给出从监控机至目标机各个网络路径的平均时间。当客户端在连接一个远程服务器时，路径并不是唯一的，受到路由器的路由选择，可能会选择不同的路径最终访问到服务器。在图533中列出了从监控服务器至目标服务器所经历的路径，以及每个路径上的网络延迟。图5.33
42、 Network Sub-Path timeNetwork Segment Delay Time这里给出各个路径上的各个节点网络延迟情况。和图533不同的地方在于，这里给出的是路由器和路由器之间的网络延迟情况，针对连接而不是路径。图534中给出了路由器和路由器之间的网络延迟变化情况，以便于分析影响整个网络时间的原因及节点。图5.34 Network Segment Delay Time5.3.7 Resources(资源监控)资源包括很多种，在Analysis中监控的都是各种系统的计数器，这些计数器反映了系统中硬件或者软件的运行情况，通过它可以发现系统瓶颈。System Resources(系
43、统资源)这里给出了对操作系统计数器的监控，列出了在负载过程中系统的各种资源数据是如何变化的，该图需要在场景中设置了对应系统的监控后才出现。Database Server Resources(数据库资源)这里给出了数据库的相关资源在负载过程中的变化情况。Web Server Resources(Web服务器资源)这里给出了Web服务器资源在负载过程中的变化情况。对于各种资源类的图来说，最困难的是理解各个计数器的含义。好比体检时会涉及血液化验，当一张血液化验单放在你面前时，普通用户是无法理解化验结果数据所反映的含义，现在通常会在化验报告单上简单介绍各个检查项目的含义，红细胞一般是在什么范围内，如果
44、少了说明贫血。当进行性能瓶颈定位时，必须掌握常见各种计数器的含义和可能导致该结果的原因。计数器分析接着介绍一下各种在性能测试中需要监控的常见计数器名称及其含义和出现瓶颈的特征，供大家参考，更为具体的内容请参考各种应用的专用调优手册和计数器手册。如何获得硬件计数器瓶颈或者各种计数器瓶颈数据?可以先通过第三方工具对系统进行负载，监控在该负载下各个计数器的最高值是多少。当用LoadRunner进行负载时，如果该计数器达到该数据，则可以说明这个计数器出现了瓶颈。例如：通过磁盘工具对物理磁盘进行压力测试，在这个过程中可以监控到物理磁盘的读写速度计数器峰值为x。当我们用LoadRunner进行负载时，如果
45、物理磁盘读写计数器数据逐步变大且最终达到X，就可以说明物理磁盘出现读写瓶颈。CPU监控常用的计数器及含义如表51所示。表5.1 CPU常用计数器内存监控常用的计数器及含义如表52所示。表52内存常用计数器物理磁盘监控常用的计数器及含义如表5_3所示。表53物理磁盘常用计数器线程监控常用的计数器及含义如表54所示。表54线程常用计数器进程监控常用的计数器及含义如表55所示。表55进程常用计数器SQL Server监控常用的计数器及含义如表56所示。表5.6 SQL Server常用计数器 Web Service Cache服务缓存监控常用的计数器及含义如表57所示。表57服务缓存常用计数IIS监
46、控常用的计数器及含义如表58所示。表5811$常用计数器网络监控常用的计数器及含义如表59所示。表59网络常用计数器ASP.NET监控常用的计数器及含义如表510所示。表5.10 ASP.NET常用计数器Apache监控常用的计数器及含义如表511所示。表511Apache常用计数器MySQL监控常用的计数器及含义如表512所示。表5.12 MySQL常用计数器Oracle监控常用的计数器及含义如表513所示。表513 Oracle常用计数器WebLogic监控常用的计数器及含义如表514所示。表514 WebLogic常用计数器5.4 图设置与操作在Analysis中经常需要和各种图打交道，那么我们需要对图的常见功能设置有所了解，在图上可以单击鼠标右键打开设置菜单，对图形进行一定的设置。SetFilterGroupBy(图的过滤规则设置)不同图的设置是不同的，主要是根据某些属性进行一定的过滤，来方便显示。SetGranularity(图的采样点间距)Analysis会自动根据场景运行的时间来设置数据采样点的间距，单位为秒。采样点越小，越能反映数据微小的变化；而采样点越大，则能反映系统在大趋势上的表现。View Cursor(打开鼠标指针)为鼠标在图