性能测试进阶指南：Loadrunner实战91-第5章 数据收集分析

1、.：.；目录 TOC o 1-3 h z u HYPERLINK l _Toc298338050 第5章 数据搜集分析Analysis PAGEREF _Toc298338050 h 2 HYPERLINK l _Toc298338051 5.1 新建Analysis分析 PAGEREF _Toc298338051 h 2 HYPERLINK l _Toc298338052 5.2 Analysis Summary PAGEREF _Toc298338052 h 2 HYPERLINK l _Toc298338053 5.2.1 Analysis Summary(场景的摘要) PAGEREF

2、_Toc298338053 h 3 HYPERLINK l _Toc298338054 5.2.2 Statistics Summary(场景形状的统计阐明) PAGEREF _Toc298338054 h 3 HYPERLINK l _Toc298338055 5.2.3 5Worst Transaction(SLA失败事务) PAGEREF _Toc298338055 h 4 HYPERLINK l _Toc298338056 5.2.4 Scenario Behavior Over Time(场景行为综述) PAGEREF _Toc298338056 h 5 HYPERLINK l _T

3、oc298338057 5.2.5 Transaction Summary(事务摘要) PAGEREF _Toc298338057 h 5 HYPERLINK l _Toc298338058 5.2.6 Service Level Agreement Legend(SLA图标阐明) PAGEREF _Toc298338058 h 7 HYPERLINK l _Toc298338059 5.2.7 Responses Summary(HTTP呼应摘要) PAGEREF _Toc298338059 h 7 HYPERLINK l _Toc298338060 5.3 Graphs(数据图) PAGE

4、REF _Toc298338060 h 8 HYPERLINK l _Toc298338061 5.3 .1 Vusers(虚拟用户形状) PAGEREF _Toc298338061 h 10 HYPERLINK l _Toc298338062 5.3.2 Errors(错误统计) PAGEREF _Toc298338062 h 11 HYPERLINK l _Toc298338063 5.3.3 Transactions(事务) PAGEREF _Toc298338063 h 11 HYPERLINK l _Toc298338064 5.3.4 WebResources(网页资源信息) PA

5、GEREF _Toc298338064 h 15 HYPERLINK l _Toc298338065 5.3.5 Web Page Diagnostics(网页分析) PAGEREF _Toc298338065 h 17 HYPERLINK l _Toc298338066 5.3.6 Network Monitor(网络监控) PAGEREF _Toc298338066 h 22 HYPERLINK l _Toc298338067 5.3.7 Resources(资源监控) PAGEREF _Toc298338067 h 23 HYPERLINK l _Toc298338068 5.4 图设置

6、与操作 PAGEREF _Toc298338068 h 34 HYPERLINK l _Toc298338069 5.4.1 Merge Graphs (合并图) PAGEREF _Toc298338069 h 34 HYPERLINK l _Toc298338070 5.4.2 Auto Correlate(自动定位瓶颈) PAGEREF _Toc298338070 h 37 HYPERLINK l _Toc298338071 5.5 Transaction Report(事务报告) PAGEREF _Toc298338071 h 40 HYPERLINK l _Toc298338072 5

7、.6 SLA Report(系统阈值监控报告) PAGEREF _Toc298338072 h 42 HYPERLINK l _Toc298338073 5.7 External Monitor(外部监控数据导入) PAGEREF _Toc298338073 h 43 HYPERLINK l _Toc298338074 5.8 Cross with result(跨脚本横向比较) PAGEREF _Toc298338074 h 45 HYPERLINK l _Toc298338075 5.9 生成测试报告 PAGEREF _Toc298338075 h 46 HYPERLINK l _Toc2

8、98338076 5.9.1 创建HTML报告 PAGEREF _Toc298338076 h 46 HYPERLINK l _Toc298338077 5.9.2 创建Word报告 PAGEREF _Toc298338077 h 47 HYPERLINK l _Toc298338078 5.9.3 创建水晶报表 PAGEREF _Toc298338078 h 47 HYPERLINK l _Toc298338079 小结 PAGEREF _Toc298338079 h 49第5章 数据搜集分析Analysis经过场景完成负载后，我们完成了性能测试的执行过程，接着就是经过负载的结果来发现和定位

9、性能瓶颈。在这里Analysis就好比一个数据分析中心或数据仓库，它将场景运转中所能得到的数据都整合在一同，可以对测试结果数据进展整理，并提供了一些方法可以进一步对结果数据进展分析，从而找出系统的性能目的和能够的瓶颈，最终生成报告。可以把Analysis看作一个股票分析软件，将股票的数据搜集分析后生成K线图，而详细阐明了什么，还要依赖于分析者本身。运用Analysis进展性能测试结果的分析流程如图5.1所示。图5.1 Analysis结果分析流程5.1 新建Analysis分析导入场景数据生成Analysis报告的方式有以下三种：当场景运转终了后在场景直接运转Results菜单下的Analyz

10、e Results命令进入Analysis。2在Analysis中翻开新建菜单，然后进入场景运转终了后的场景结果res目录，接着Analysis会对整个场景数据进展整理，给出简明报告及相关图表。3在场景结果目录中直接双击Mercury LoadRunner Result(.lrr)文件。5.2 Analysis Summary当Analysis导入场景数据后，首先映入眼帘的是统计表格Analysis Summary场景摘要，提供了对整个场景数据的简单报告。下面引见一下该报告的各个组成部分。5.2.1 Analysis Summary(场景的摘要)这里给出了场景的摘要(Analysis Summ

11、ary)，包括以下内容：Period：场景运转的起止时间Scenario Name：场景称号Resultsin Session：场景运转的结果目录Duration：场景运转的时间经过场景摘要可以了解场景执行的根底信息。5.2.2 Statistics Summary(场景形状的统计阐明)场景形状的统计阐明(Statistics Summary)包含以下内容：Maximum Running Vusers：场景最大用户数Total Throughput(bytes)：总带宽流量Average Throughput(bytes/second)：平均每秒带宽流量Total Hits：总点击数Avera

12、ge Hits per Second：平均每秒点击数单击View Responses Summary选项可以切换到报告的最下端查看HTTP恳求的统计。在每项数据标题和数据中，还会看到一个小的球形图标囊，单击后会进入SLA分析报告。5.2.3 5Worst Transaction(SLA失败事务)这里列出了对5大失败事务的统计，只需当在Controller或Analysis中定义了SLA status determined at time intervals over a timeline监控时才会出现该报告。Transaction Name(事务名)。Failure Ratio(exceede

13、d time/transaction duration)失败率(超标次数/事务继续时间)。该值反映了在一切事务中有百分之多少的事务是无法到达SLA基准值。Failure Value(response time/SLA)失败率(呼应时间/SLA)。该值反映了在整个场景运转下，SLA的定义规范值与实践事务值超标的平均百分比，也就是说平均算下来真实的呼应时间和定义的阈值误差百分比。经过这行报告，我们可以明晰地了解该事务有多少是无法到达SLA规范的，以及无法到达规范的事务与SLA的误差范围是多少。单击事务名前的加号还能列出该事务在SLA定义的继续时间下平均误差比例和最大误差比例。Analysis会根据

14、SLA中的定义分析事务的经过率，在这个场景结果中，一切的事务呼应时间都在SLA监控值以外，所以结果为Infinity全部超标。分析的失败事务数可以在Tools菜单下Options的General标签中进展设置，默以为5个事务，如图52所示。图52 SummaryReport设置5.2.4 Scenario Behavior Over Time(场景行为综述)这里列出了在场景中定义的事务在各个时间点上的SLA情况，背景中的x表示在这个时间点上事务没有到达SLA的目的。而上面的Application Under Test Errors显示了在每个时间段上的错误数目。5.2.5 Transactio

15、n Summary(事务摘要) 这里首先给出的是场景中一切事务的情况阐明：TotalPassed(事务的总经过数)TotalFailed(事务的总失败数)TotalStopped(事务的总停顿数)Average Response Time是一个链接，可以翻开事务平均呼应时间图表。下面给出每个详细事务的情况列表，可以看到以下数据项：Transaction Name(事务名)SLA Status(SLA形状)：在SLA的目的测试中最终结果是经过还是失败Minimum(事务最小时间)Average(事务平均时间)Maximum(事务最大时间)Std.Deviation(规范方差)规范方差，这个数据是

16、描画采样数据离散形状很重要的目的，它又分为以下两种：1给定样本规范方差，它是估算给定样本而不是整个样本的规范方差(也就是样本中的一部分)，计算公式如下：其中X代表平均值，n代表取样个数。n-1是统计学上的常用做法，主要思索到采样量越大，越能反映真实的情况。2总体样本规范方差，它是估算整个采样样本的规范方差(留意是整个采样数据而不是部分)，计算公式如下：当采样数据足够大的时候，上述两种计算方式得出的偏向相差很小。规范方差相对于平均值越大，阐明数据越离散，那么分布形状相对于平均值动摇很大；规范方差相对于平均值越小，阐明数据分布越集中，曲线也越平稳。在采样值服从正态分布的条件下经过上面的目的结合平均

17、值、最大值、最小值，可以比较清楚地知道采样数据的分布形状及其能否有较大的动摇。90Percent(用户感受百分比)这个值阐明的采样数据中有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(事

18、务经过数)Fail(事务失败数)Stop(事务停顿数)5.2.6 Service Level Agreement Legend(SLA图标阐明) 图标为灰色带减号的为No Data，阐明在SLA中未对这个数据项进展监控，没有数据；图标为红色带叉的为Fail，阐明在SLA中定义了该项的数据监控，但该数据未能到达期望的阈值；图片为绿色带钩的为Pass，阐明在SLA中定义了该项的数据监控，该数据到达了的期望阈值。5.2.7 Responses Summary(HTTP呼应摘要)这里给出了效力器前往的形状。效力器前往HTTP恳求形状( Responses，详细的效力器前往形状码见附录A)HTTP恳求前

19、往次数(Total)每秒恳求数(Per second)经过Analysis Summary可以对整个性能测试的结果有一个直观的引见，特别是经过SLA的数据可以直观地了解在整个负载中系统的性能目的能否满足阈值，除此以外设置的事务呼应时间数据也会显示。Analysis保管后会生成Mercury LoadRunner Analysis Session(lra)文件。经过File菜单下的Session Information功能可以了解该Session文件的属性，而File菜单下的View Scenario RunTime Settings功能可以查看该报告场景的运转设置。当粗略了解了整个场景的情况后

20、，根据场景执行前的目的，可以对整个系统的性能有一定的了解，接着需求对关怀的数据进展进一步的了解和分析。5.3 Graphs(数据图)在场景运转时可以看到一些图，这些图将场景中的数据转化为折线图，方便我们了解当前该数据的形状。在默许情况下，Analysis会自动翻开如图53所示的几张图。这是系统最根本的几个图，这些图反映了在不同时间段相关计数器的数据变化情况，可以经过在Graphs上右键菜单中的Add New Graphs命令完成添加图的操作，添加后弹出Graphs管理器，如图5.4所示。在Open a NewGraph窗口中，可以得到一切能添加的计数器图形，勾选左下角的Display only

21、 graphs containing data选项可以隐藏没有数据的计数器，有数据的计数器那么会以蓝色显示在左侧区域。而选中详细的图，在右侧的Graph Description中会有更加详细的引见。在Graph Properties中还可以对生成的图表进展一定的属性设置，例如生成的图是运用整个场景的时间还是其中的某一部分时间。 图53默许情况下系统翻开的Graphs图54数据图管理器对于恣意一张图，都可以在右侧看到有2个功能：User Notes和Raw Data。UserNotes提供对某张图进展文字描画的功能；Raw Data是将生成该图的数据列出。在RawData中单击Click to

22、retrieve raw data，会弹出Raw Data窗口，设置场景继续的时间，确认后可以得到该时间段内组成该图的一切数据，如图55所示。图5.5 RawData数据表这里可以将数据另存为Excel文件，再经过第三方工具进展分析。例如将导出的场景数据运用SPSS工具进展进一步的数学分析。在图的下方，Legend窗口会显示图中对象阐明信息以及相关数据，如图56所示。经过对显示对象的一些设置，可以得到更好的显示效果。在Legend窗口中单击鼠标右键，弹出菜单如图57所示。图56Legend图中对象数听阐明图57Legend设置选项菜单可以经过Show/Hide/Show only select

23、ed/Show all命令设置所需求选的工程，也可以经过Configure measurements/Show measurement description命令设置线条的颜色及显示方式。Animate selected line选项可以在切换线条时获得更加明显的动画效果，Auto Correlate提供了对所选对象的自动关联操作(参考542节)，而在Configure columns中可以设置在Legend中显示哪些属性名。每张图都代表了场景运转中监控到的数据变化趋势，所以看懂每一张图的含义是性能分析的第一步，接着我们来引见一些常见图的含义。5.3 .1 Vusers(虚拟用户形状)Vuse

24、rs用户形状计数器组提供了产生负载的虚拟用户运转形状的相关信息，可以协助 我们了解负载生成的过程。Running Vusers(负载过程中的虚拟用户运转情况)该图可以反映系统构成负载的过程，随着时间的推移，虚拟用户数是如何变化的。在图58中可以看到用户在9分钟左右到达了负载峰值50个虚拟用户，负载的生成是大约每分钟添加5个用户，峰值负载继续1分30秒。图5.8 Running VusersRendezvous(负载过程中集合点下的虚拟用户数)当场景中设置了集合点后会出现这张图，该图反映了随着时间的推移各个时间点上并发用户的数目，方便我们了解并发用户数的变化情况。在图59中可以看到刚开场的7分钟

25、内，负载的并发用户都是1个，而后面变化为2个用户并发。图5.9 Rendezvous5.3.2 Errors(错误统计)当场景在运转中出现错误时，错误信息将会被保管在该计数器组中，经过Error信息可以了解错误产生的时间和错误的类型，协助 我们定位产生错误的缘由。Errors per Second(每秒错误数)经过每秒错误数可以了解在每个时间点上错误产生的数目，该数据越小越好。经过这个图可以了解错误随负载的变化情况，定位何时系统在负载下开场不稳定甚至出错，配合系统日志可以定位产生错误的缘由。在图510中可以看到场景在37秒的时候出现了一次错误。图5.10 Errors per Second5.

26、3.3 Transactions(事务)这里给出了一切和事务相关的数据统计，方便了解被测系统业务处置的呼应时间和吞吐量，在39节中引见了系统事务默许有3种形状PASS、FAIL、STOP，假设是手工事务那么形状会有PASS和FAIL两种。Average Transaction Response Time(平均事务呼应时间)这是我们比较关怀的数据之一，反映随着时间的变化事务呼应时间的变化情况，时间越小阐明处置的速度越快。假设和前面的用户负载生成图合并在一同看，就可以发现用户负载添加对系统事务呼应时间的影响规律。在图511中可以看到呼应时间是如何增长的，随着时间的推移呼应时间逐渐变长，并且在不到8

27、分钟的时候忽然出现呼应时间大幅下降的情况。图5。11 Average Transaction Response Time另外事务的呼应时间也不应该超越用户的最大接受范围，否那么会出现系统呼应过慢的问题。Transactions per Second(每秒事务数)另一个关键数据是TPS吞吐量，该数据反映了系统在同一时间内能处置业务的最大才干，这个数据越高，阐明系统处置才干越强。在图512中上面的线是经过的事务，下面的线是失败的事务，这里可以看到系统的TPS随着时间的变化逐渐变大，而在不到10分钟的时候系统每秒可以处置1.9个事务。这里的最高值并不一定代表系统的最大处置才干，TPS会遭到负载的影响

28、，也会随着负载的添加而逐渐添加，当系统进入忙碌期后，TPS会有所下降。而在4分钟以后开场出现少量的失败事务。图5.12 Transactions per SecondTransactionSummary(事务概要阐明)该阐明给出事务的Pass个数和Fail个数，了解负载的事务完成情况。经过的事务数越多，阐明系统的处置才干越强；失败的事务越少，阐明系统越可靠。在图513中可以看出，对于reg注册操作一共有613次操作胜利，有6次失败。可以思索结合前面的每秒错误数进一步分析为什么会出现6个注册错误，以及错误发生的时间和该时间产生错误的缘由。图5.13 Transaction SummaryTran

29、saction PerformanceS ummary(事务性能概要)这里会给出事务的平均时间、最大时间、最小时间柱状图，方便分析事务呼应时间的情况。在图5.14中可以看到reg这个事务最大时间为3.897s，最小时间为2.555s，平均时间为2.924s。柱状图的落差越小阐明呼应时间的动摇较小，假设落差很大，那么阐明系统不够稳定。图5.14 Transaction Performance SummaryTransaction Response Time Under Load(在用户负载下事务呼应时间)这里给出了在负载用户增长的过程中呼应时间的变化情况，其实这张图也是将Vusers和Avera

30、ge Transaction Response Time图做了一个Correlate Merge得到的，该图的线条越平稳，阐明系统越稳定。在图5.15中可以看出在负载逐渐添加到5个用户时，事务的呼应时间根本没有变化。而用户添加到15个开场，随着用户负载的添加呼应时间也有较大的动摇。 图5.15 Transaction Response Time Under LoadTransaction Response Time(Percentile)(事务呼应时间的百分比)这里给出的是不同百分比下的事务呼应时间范围，经过这个图可以了解有多少比例的事务发生在某个时间内，也可以发现呼应时间的分布规律，数据越平

31、稳阐明呼应时间变化越小。在图5.16中可以看到60的事务是在3秒内。图5.16 Transaction Response Time(Percentile)Transaction Response Time(Distribution)(每个时间段上的事务数)该图给出的是在每个时间段上的事务个数，呼应时间较小的分类下的事务数越多越好。从图5.17中可以看到在一切的事务中，有391个事务的呼应时间最接近2秒，而有222个事务的呼应时间最接近3秒。图5.17 Transaction Response Time(Distribution)5.3.4 WebResources(网页资源信息)这里给出的是对

32、于Web操作的一些根本信息，这些信息在效力器端也能获得。当Controller的RunTime Setting中Preferences下的Generated Web performance graphs选项处于开启形状时，该图表才会出现。Hits per Second(每秒点击数)每秒点击数提供了当前负载中对系统所产生的点击量记录。每一次点击相当于对效力器发出了一次恳求，普通点击数会随着负载的添加而添加，该数据越大越好。在图5.18中可以看出随着时间的添加，每秒点击数在上升，最高到达78次s。图5.18 Hits per SecondThroughput(带宽运用)这里给出了在当前系统负载下所

33、运用的带宽，该数据越小阐明系统的带宽依赖越小，经过这个数据能确定能否出现了网络带宽的瓶颈(留意这里运用的单位是字节)。在图5.19中可以得到最高的带宽峰值是355000B，远远低于100Mb的局域网带宽上限，所以系统不存在带宽瓶颈。图5.19 Throughput Responses per Second(每秒HTTP呼应数)这里给出了每秒钟效力器前往各种形状的数目，该数值普通和每秒点击量一样。点击量是指客户端发出的恳求数，而HTTP呼应数是指效力器前往的呼应数。假设效力器前往的呼应数小于客户端发出的点击数，那么阐明效力器无法应对超出负载的衔接恳求。在图5.20中可以看到最顶峰时效力器每秒能前

34、往接近75个HTTP 200 OK的形状。图5.20 responses per Second这个数据和前面的每秒点击数吻合，阐明效力器可以对每一个客户端恳求进展应对。Connections Per Second(每秒衔接数)这里会给出两种不同形状的衔接数，即中断的衔接和新建的衔接，方便用户了解当前每秒对效力器产生衔接的数量。在图5.21中可以看到随着时间的推移，系统的衔接数逐渐上升，最高到达每秒4个衔接。图5.21 Connections Per Second同时的衔接数越多，阐明效力器的衔接池越大，当衔接数随着负载上升而停顿上升时，阐明系统的衔接池已满，无法衔接更多的用户，通常这个时候效力

35、器会前往504错误。可以经过修正效力器的最大衔接数来处理该问题。5.3.5 Web Page Diagnostics(网页分析)当在场景中翻开Diagnostics菜单下的Web Page Diagnostics功能，就能得到网页分析组图。经过这个图，可以对事务的组成进展抽丝剥茧的分析，得到组成这个页面的每一个恳求时间分析，进一步了解呼应时间中有关网络和效力器处置时间的分配关系。经过这个功能，可以实现对网站的前端性能分析，明确系统呼应时间较长是由效力器端(后端)处置才干缺乏还是客户端衔接到效力器的网络(前端)耗费导致的。更多内容参考6.1.5节中的前端性能分析。Web Page Diagnos

36、tics(网页分析)添加该图先会得到整个场景运转后虚拟用户访问的Page列表，也就是一切页面下载时间列表。这里对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

37、秒上升到了3.9秒，并且在7分30秒时大幅下滑，回到2.6秒左右。图5.23 Web Page Diagnostics对用户注册页面细分在Diagnostics options选项中提供了以下4大块功能。Download Time(下载时间分析)这里可以得到组成页面的每个恳求下载时间。在图5.24中可以看到创建用户的操作由4个恳求组成，其中导致注册用户较慢的主要缘由是注册完成后需求等待两秒钟再刷新至论坛首页，而非注册用户本身需求耗费的时间。首页刷新慢也只是由于Client(客户端)需求耗费较多时间，同时Receive(接纳)的时间也有一定的影响。图5.24 Web Page Diagnosti

38、cs Download TimeComponent(Over time)(各模块的时间变化)这里列出组成页面的每个元素，以及随着时间的变化所带来的呼应时间变化。经过这个功能可以分析呼应时间变长是由于页面生成慢，还是由于图片资源下载慢。在图5.25中可以发现随着时间的添加，首页的处置时间(最上面的一根线)从0.5秒上升到了最大值16秒，而注册用户呼应时间几乎没有上升。图5.25 Web Page Diagnostics Component(Over Time)Download Time(Over time)(模块下载时间)这里提供了针对每个组成页面元素的时间组成部分分析，方便确认该元素的处置时间

39、组成部分。在图526中可以发现首页恳求的下载时间主要耗费在Client上，而7分30秒之前Recevie所耗费的时间在逐渐变长。图5.26 Web Page Diagnostics Download Time(Over Time)Time to First Buffer(Over time)(模块时间分类)这里会列出该元素所运用的时间分配比例，是受Network Time影响的多还是ServerTime影响的多。在图5.27中可以看出，对于首页刷新的呼应时间来说，主要是NetworkTime网络上耗费的时间，而Server Time效力器端的处置是非常优秀的。ServerTime是指效力器对该

40、页面的处置时间；Network Time是指网络上的时间开销。图5.27 WebPage Diagnostics Time to First Buffer(Over time)经过这4个分析图，我们可以了解到对于事务的呼应时间来说，效力器的处置时间并不是组成呼应时间的主要部分，而网络问题通常会占用超越70的时间，经过Web Page Diagnostics可以准确分析呼应时间，防止由于网络延迟或者带宽问题而影响对呼应时间的分析和瓶颈定位。在LoadRunner的安装目录下找到LRAnalysis80.ini文件，在其中的WPB下添加SURLSize=255，另外还需求修正loader2.mdb

41、文件，将其中Breakdown-map表中的EventName的属性长度从50修正为255，在以后场景运转结果的报告中就可以显示最长为255字符的途径称号了。Page Download Time Breakdown(页面呼应时间组成分析)这张图中显示了每个页面呼应时间的组成分析，一个页面的呼应时间普通由以下内容组成：Client Time客户端阅读器接纳所需求运用的时间，可以不用思索。Connections Time衔接效力器所需求的时间，越小越好。DNS Resolution Time经过DNS效力器解析域名所需求的时间，解析遭到DNS效力器的影响，越小越好。Error Time效力器前往错

42、误呼应时间，这个时间反映了效力器处置错误的速度，普通是Web效力器直接前往的，包含了网络时间和Web效力器前往错误的时间，该时间越小越好。First Buffer Time衔接到效力器，效力器前往第一个字节所需求的时间，反映了系统对于正常恳求的处置时间开销，包含网络时间和效力器正常处置的时间，该时间越小越好。FTP Authentication Time FTP认证时间，这是进展FTP登录等操作所需求耗费的认证时间，越短越好。Receive Time接受数据的时间，这个时间反映了带宽的大小，带宽越大，下载时间越短。SSL Handshaking TimeSSL加密握手的时间。而Analysis

43、在这里会分析得到页面恳求的组成比例图，便于分析页面时间浪费在哪些过程中。在图5.28中可以看到各个页面恳求的呼应时间组成情况，相对于00的首页恳求，时间主要浪费在Client上。图5.28 Page Download Time BreakdownPage Download Time Breakdown(Over Time)(页面组成部分时间)这里提供了随着时间的变化一切恳求的呼应时间变化过程。这里会将整个负载过程中每个页面的每个时间组成部分都做成单独的时间线，以便分析在不同的时间点上组成该页面的各个恳求时间是如何变化的。在图5.29中可以看到大多数页面的呼应时间是比较稳定的，其中首页刷新变动较

44、大。图529 Page Download Time Breakdown(Over Time)首先找到变化最明显或者呼应时间最高的页面，随后再针对这个页面进展进一步的分析了解时间偏长或者变化较快的缘由。Time to First Buffer Breakdown(页面恳求组成时间)这里提供了组成页面时间恳求的比例阐明(客户端时间/效力器时间)，经过这个图，我们可以直观地了解到整个页面的处置是在效力器端耗费的时间长，还是在客户端耗费的时间长，从而分析得到系统的性能问题是在前端还是在后端。在图5.30中可以看出对于整个负载来说，网络或客户端的时间开销占了绝大多数。Time to First Buff

45、er Breakdown(Over Time)(基于时间的页面恳求组成分析)和图530不同的是，这里给出了在整个负载过程中，每一个恳求的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(网络监控)假设在

46、Controller中添加了Network Delay Time监控后会出现该数据图。这个功能很好但并不是非常直观和方便，建议运用第三方专门的路由分析工具进展网络延迟和途径分析。Network Delay Time这里会给出从监控机至目的主机的平均网络延迟变化情况。在图532中可以看到网络延迟从240毫秒逐渐减少到26毫秒，最后上升到340毫秒。图532 Network Delay TimeNetwork Sub-Path Time这里给出从监控机至目的机各个网络途径的平均时间。当客户端在衔接一个远程效力器时，途径并不是独一的，遭到路由器的路由选择，能够会选择不同的途径最终访问到效力器。在图5

47、33中列出了从监控效力器至目的效力器所阅历的途径，以及每个途径上的网络延迟。图5.33 Network Sub-Path timeNetwork Segment Delay Time这里给出各个途径上的各个节点网络延迟情况。和图533不同的地方在于，这里给出的是路由器和路由器之间的网络延迟情况，针对衔接而不是途径。图534中给出了路由器和路由器之间的网络延迟变化情况，以便于分析影响整个网络时间的缘由及节点。图5.34 Network Segment Delay Time5.3.7 Resources(资源监控)资源包括很多种，在Analysis中监控的都是各种系统的计数器，这些计数器反映了系统

48、中硬件或者软件的运转情况，经过它可以发现系统瓶颈。System Resources(系统资源)这里给出了对操作系统计数器的监控，列出了在负载过程中系统的各种资源数据是如何变化的，该图需求在场景中设置了对应系统的监控后才出现。Database Server Resources(数据库资源)这里给出了数据库的相关资源在负载过程中的变化情况。Web Server Resources(Web效力器资源)这里给出了Web效力器资源在负载过程中的变化情况。对于各种资源类的图来说，最困难的是了解各个计数器的含义。好比体检时会涉及血液化验，当一张血液化验单放在他面前时，普通用户是无法了解化验结果数据所反映的含

49、义，如今通常会在化验报告单上简单引见各个检查工程的含义，红细胞普通是在什么范围内，假设少了阐明贫血。当进展性能瓶颈定位时，必需掌握常见各种计数器的含义和能够导致该结果的缘由。计数器分析接着引见一下各种在性能测试中需求监控的常见计数器称号及其含义和出现瓶颈的特征，供大家参考，更为详细的内容请参考各种运用的公用调优手册和计数器手册。如何获得硬件计数器瓶颈或者各种计数器瓶颈数据?可以先经过第三方工具对系统进展负载，监控在该负载下各个计数器的最高值是多少。当用LoadRunner进展负载时，假设该计数器到达该数据，那么可以阐明这个计数器出现了瓶颈。例如：经过磁盘工具对物理磁盘进展压力测试，在这个过程中

50、可以监控到物理磁盘的读写速度计数器峰值为x。当我们用LoadRunner进展负载时，假设物理磁盘读写计数器数据逐渐变大且最终到达X，就可以阐明物理磁盘出现读写瓶颈。CPU监控常用的计数器及含义如表51所示。表5.1 CPU常用计数器内存监控常用的计数器及含义如表52所示。表52内存常用计数器物理磁盘监控常用的计数器及含义如表5_3所示。表53物理磁盘常用计数器线程监控常用的计数器及含义如表54所示。表54线程常用计数器进程监控常用的计数器及含义如表55所示。表55进程常用计数器SQL Server监控常用的计数器及含义如表56所示。表5.6 SQL Server常用计数器 Web Servic

51、e Cache效力缓存监控常用的计数器及含义如表57所示。表57效力缓存常用计数IIS监控常用的计数器及含义如表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 W

52、ebLogic常用计数器5.4 图设置与操作在Analysis中经常需求和各种图打交道，那么我们需求对图的常见功能设置有所了解，在图上可以单击鼠标右键翻开设置菜单，对图形进展一定的设置。SetFilterGroupBy(图的过滤规那么设置)不同图的设置是不同的，主要是根据某些属性进展一定的过滤，来方便显示。SetGranularity(图的采样点间距)Analysis会自动根据场景运转的时间来设置数据采样点的间距，单位为秒。采样点越小，越能反映数据微小的变化；而采样点越大，那么能反映系统在大趋势上的表现。View Cursor(翻开鼠标指针)为鼠标在图中添加横向和纵向的标尺，方便了解鼠标所在位

53、置的横坐标和纵坐标。View Raw Data(翻开图所对应的数据)Comments(注释)在图中添加注释，便于阐明某些问题。Clear Display Options(去掉一切的显示选项)该选项可以回到最原始的数据图方式，去掉一切的过滤和显示设置。Display Options(显示方式选项)设置图的显示方式，经过这个选项可以将图调整得更加美观，例如将图转化为3D方式或调整线条颜色及背景颜色等。5.4.1 Merge Graphs (合并图)当得到了相关图形，如何分析图和图之间的关系呢?MergeGraphs提供了一种将图和图合并的功能，经过这个功能可以直观地获得一个数据和另外一个数据的相互

54、影响关系。在RunningVusers图中，单击鼠标右键，在菜单中选择MergeGraphs，如图535所示。Merge的方式有3种：Overlay、Tile、Correlate，如图536所示。这3种合并方法可以协助 我们对测试结果进展分析，了解图和图之间的影响关系。Overlay基于Overlay合并方式，就是将两张图经过x轴进展覆盖合并。例如将RunningVusers和AverageTransactionResponseTime进展Overlay合并，如图537所示。 图5.35 Merge Graphs 图5.36 Merge方式设置图5.37 Overlay的Merge方式经过这张

55、图可以得到用户增长的过程是如何影响事务平均时间的，从而发现瓶颈出现的时间。TileTile的方式和Overlay的方式非常接近，只是将两张图的y轴分了上下两部分，不做重叠。将Running Vusers和Hits per Second进展Tile合并，如图538所示。图5.38 Tile的Merge方式经过这个合并，可以看到随着用户数量添加每秒点击量的变化过程，从而了解在当前负载下系统接受的点击量峰值。相对于Overlay方式，两张图的线条不会重叠在一同，看起来更加清楚。Correlate这个合并比较复杂，首先将主图的Y轴变为x轴，而被合并图的y轴依然保管为y轴，按照各图本来的时间关系进展合并

56、构成新图。例如这里将Running Vusers和Transactions per Second两张图进展Correlate合并，如图539所示。图539Correlate的Merge方式系统将Running Vusers图的Y轴作为新图的x轴，将Transactions per Second图的y轴作为新图的y轴。在经过Correlate方式合并后的图中，可以更加明晰地看出用户变化导致处置才干的变化过程，斜率越大阐明影响越大，方便快速定位在何种负载下系统呼应时间可以稳定，而在何种负载下呼应时间会大幅上升。经过这几种常见的Merge方法，可以将相关计数器得到的图进展合并分析，找出系统性能的瓶颈

57、。由于系统瓶颈的定位需求大量的相关知识，对于一个初级性能测试工程师来说，并不要求有性能结果分析和性能瓶颈定位的才干。初级性能测试工程师可以将数据整理后提交给工程经理、网络或数据库管理员，让他们协助 他分析数据，并确认及完成性能调优任务。5.4.2 Auto Correlate(自动定位瓶颈)Auto Correlate提供了自动分析趋势影响的功能，经过它可以方便地找出哪些数据之间有明显的相互依赖性，经过图和图之间的关系确认系统资源和负载相互影响的关系。首先找到需求自动关联的图，右键翻开Auto Correlate菜单。例如选择从Running Vusers图上做自动关联，如图540所示。弹出自

58、动关联窗口，如图541所示。我们需求进展以下设置。1Time Range设置关联的时间范围标签。Suggest Time Range by提供了自动关联的范围参考，可以选择Trend基于趋势或者选择Feature基于特征两种方式。这两种方式可以自动选择关联的范围，Trend完好包含一切值得留意、分析的趋势，而Feature那么是其间一个单独的片段。例如这里选择Feature，如图542所示。 图5.40 Auto Correlate 图5.41 Auto Correlate设置图5.42 Auto Correlate设置基于Feature特征的时间方式右侧的竖线就会换到6分钟的位置，由于从0分

59、到6分是用户负载上升的阶段，这个阶段的特征就是添加。经过单击Next按钮可以切换到下一个特征，下一个特征是6分40秒至7分04秒的负载下降阶段，如图5.43所示。图5.43 Auto Correlate设置基于Feature特征的时间方式切换可以经过拖动图中的两根竖线来确定关联的范围或直接修正From后的时间来调整关联的范围。这样就确认了希望关联的时间范围，接着需求设置被关联的对象。2Correlation Options切换到Correlation Options标签，这里列出了一切和当前图可以进展关联的对象，默许选择了3个资源图，用户也可以自行设置需求关联的图，另外可以在Data Inte

60、rval中设置数据点的间隔和Output中的输出情况，如图544所示。图5.44 Auto Correlate关联选项Data Interval是指自动关联的数据间隔，默以为5秒钟，也可以手工设定关联的数据间隔。间隔的时间设置越小得出的关联匹配度越准确。Output是对输出关结合果的设置，可以选择设置显示和被关联图匹配值最高的5个对象，也可以设置显示一切和被关联图匹配值大于50的对象。这里修正Select measurement categories选择对象为Hits per Second，其他选项坚持默许值，确定后得到最终的自动关结合果，如图545所示。图5.45 Auto Correlat