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

目录第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 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 Report(事务报告)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就好比一个数据分析中心或数据仓库，它将场景运行中所能得到的数据都整合在一起，能够对测试结果数据进行整理，并提供了一些方法可以进一步对结果数据进行分析，从而找出系统的性能指标和可能的瓶颈，最终生成报告。可以把Analysis看作一个股票分析软件，将股票的数据收集分析后生成K线图，而具体说明了什么，还要依赖于分析者自身。使用Analysis进行性能测试结果的分析流程如图5.1所示。图5.1 Analysis结果分析流程5.1 新建Analysis分析导入场景数据生成Analysis报告的方式有以下三种：1 当场景运行结束后在场景直接运行Results菜单下的Analyze Results命令进入Analysis。2在Analysis中打开新建菜单，然后进入场景运行结束后的场景结果res目录，接着Analysis会对整个场景数据进行整理，给出简明报告及相关图表。3在场景结果目录中直接双击Mercury LoadRunner Result(.lrr)文件。5.2 Analysis Summary当Analysis导入场景数据后，首先映入眼帘的是统计表格Analysis Summary场景摘要，提供了对整个场景数据的简单报告。下面介绍一下该报告的各个组成部分。5.2.1 Analysis Summary(场景的摘要)这里给出了场景的摘要(Analysis Summary)，包括以下内容：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：总点击数Average Hits per Second：平均每秒点击数单击View HTTP 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(exceeded time/transaction duration)失败率(超标次数/事务持续时间)。该值反映了在所有事务中有百分之多少的事务是无法达到SLA基准值。Failure Value(response time/SLA)失败率(响应时间/SLA)。该值反映了在整个场景运行下，SLA的定义标准值与实际事务值超标的平均百分比，也就是说平均算下来真实的响应时间和定义的阈值误差百分比。通过这行报告，我们可以清晰地了解该事务有多少是无法达到SLA标准的，以及无法达到标准的事务与SLA的误差范围是多少。单击事务名前的加号还能列出该事务在SLA定义的持续时间下平均误差比例和最大误差比例。Analysis会根据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 Transaction Summary(事务摘要) 这里首先给出的是场景中所有事务的情况说明：TotalPassed(事务的总通过数)TotalFailed(事务的总失败数)TotalStopped(事务的总停止数)Average Response Time是一个链接，可以打开事务平均响应时间图表。下面给出每个具体事务的情况列表，可以看到以下数据项：Transaction Name(事务名)SLA Status(SLA状态)：在SLA的指标测试中最终结果是通过还是失败Minimum(事务最小时间)Average(事务平均时间)Maximum(事务最大时间)Std.Deviation(标准方差)标准方差，这个数据是描述采样数据离散状态很重要的指标，它又分为以下两种：1给定样本标准方差，它是估算给定样本而不是整个样本的标准方差(也就是样本中的一部分)，计算公式如下：其中X代表平均值，n代表取样个数。n-1是统计学上的常用做法，主要考虑到采样量越大，越能反映真实的情况。2总体样本标准方差，它是估算整个采样样本的标准方差(注意是整个采样数据而不是部分)，计算公式如下：当采样数据足够大的时候，上述两种计算方式得出的偏差相差很小。标准方差相对于平均值越大，说明数据越离散，则分布状态相对于平均值波动很大；标准方差相对于平均值越小，说明数据分布越集中，曲线也越平稳。在采样值服从正态分布的条件下通过上面的指标结合平均值、最大值、最小值，可以比较清楚地知道采样数据的分布状态及其是否有较大的波动。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(事务通过数)Fail(事务失败数)Stop(事务停止数)5.2.6 Service Level Agreement Legend(SLA图标说明) 图标为灰色带减号的为No Data，说明在SLA中未对这个数据项进行监控，没有数据；图标为红色带叉的为Fail，说明在SLA中定义了该项的数据监控，但该数据未能达到期望的阈值；图片为绿色带钩的为Pass，说明在SLA中定义了该项的数据监控，该数据达到了的期望阈值。5.2.7 HTTP Responses Summary(HTTP响应摘要)这里给出了服务器返回的状态。服务器返回HTTP请求状态(HTTP Responses，具体的服务器返回状态码见附录A)HTTP请求返回次数(Total)每秒请求数(Per second)通过Analysis Summary可以对整个性能测试的结果有一个直观的介绍，特别是通过SLA的数据可以直观地了解在整个负载中系统的性能指标是否满足阈值，除此以外设置的事务响应时间数据也会显示。Analysis保存后会生成Mercury LoadRunner Analysis Session(lra)文件。通过File菜单下的Session Information功能可以了解该Session文件的属性，而File菜单下的View Scenario RunTime Settings功能可以查看该报告场景的运行设置。当粗略了解了整个场景的情况后，根据场景执行前的目标，可以对整个系统的性能有一定的了解，接着需要对关心的数据进行进一步的了解和分析。5.3 Graphs(数据图)在场景运行时可以看到一些图，这些图将场景中的数据转化为折线图，方便我们了解当前该数据的状态。在默认情况下，Analysis会自动打开如图53所示的几张图。这是系统最基本的几个图，这些图反映了在不同时间段相关计数器的数据变化情况，可以通过在Graphs上右键菜单中的Add New Graphs命令完成添加图的操作，添加后弹出Graphs管理器，如图5.4所示。在Open a NewGraph窗口中，可以得到所有能添加的计数器图形，勾选左下角的Display only graphs containing data选项可以隐藏没有数据的计数器，有数据的计数器则会以蓝色显示在左侧区域。而选中具体的图，在右侧的Graph Description中会有更加详细的介绍。在Graph Properties中还可以对生成的图表进行一定的属性设置，例如生成的图是使用整个场景的时间还是其中的某一部分时间。 图53默认情况下系统打开的Graphs图54数据图管理器对于任意一张图，都可以在右侧看到有2个功能：User Notes和Raw Data。UserNotes提供对某张图进行文字描述的功能；Raw Data是将生成该图的数据列出。在RawData中单击Click to retrieve raw data，会弹出Raw Data窗口，设置场景持续的时间，确认后可以得到该时间段内组成该图的所有数据，如图55所示。图5.5 RawData数据表这里可以将数据另存为Excel文件，再通过第三方工具进行分析。例如将导出的场景数据使用SPSS工具进行进一步的数学分析。在图的下方，Legend窗口会显示图中对象说明信息以及相关数据，如图56所示。通过对显示对象的一些设置，可以得到更好的显示效果。在Legend窗口中单击鼠标右键，弹出菜单如图57所示。图56Legend图中对象数据说明图57Legend设置选项菜单可以通过Show/Hide/Show only selected/Show all命令设置所需要选的项目，也可以通过Configure measurements/Show measurement description命令设置线条的颜色及显示方式。Animate selected line选项可以在切换线条时获得更加明显的动画效果，Auto Correlate提供了对所选对象的自动关联操作(参考542节)，而在Configure columns中可以设置在Legend中显示哪些属性名。每张图都代表了场景运行中监控到的数据变化趋势，所以看懂每一张图的含义是性能分析的第一步，接着我们来介绍一些常见图的含义。5.3 .1 Vusers(虚拟用户状态)Vusers用户状态计数器组提供了产生负载的虚拟用户运行状态的相关信息，可以帮助我们了解负载生成的过程。Running Vusers(负载过程中的虚拟用户运行情况)该图可以反映系统形成负载的过程，随着时间的推移，虚拟用户数是如何变化的。在图58中可以看到用户在9分钟左右到达了负载峰值50个虚拟用户，负载的生成是大约每分钟增加5个用户，峰值负载持续1分30秒。图5.8 Running VusersRendezvous(负载过程中集合点下的虚拟用户数)当场景中设置了集合点后会出现这张图，该图反映了随着时间的推移各个时间点上并发用户的数目，方便我们了解并发用户数的变化情况。在图59中可以看到刚开始的7分钟内，负载的并发用户都是1个，而后面变化为2个用户并发。图5.9 Rendezvous5.3.2 Errors(错误统计)当场景在运行中出现错误时，错误信息将会被保存在该计数器组中，通过Error信息可以了解错误产生的时间和错误的类型，帮助我们定位产生错误的原因。Errors per Second(每秒错误数)通过每秒错误数可以了解在每个时间点上错误产生的数目，该数据越小越好。通过这个图可以了解错误随负载的变化情况，定位何时系统在负载下开始不稳定甚至出错，配合系统日志可以定位产生错误的原因。在图510中可以看到场景在37秒的时候出现了一次错误。图5.10 Errors per Second5.3.3 Transactions(事务)这里给出了所有和事务相关的数据统计，方便了解被测系统业务处理的响应时间和吞吐量，在39节中介绍了系统事务默认有3种状态PASS、FAIL、STOP，如果是手工事务那么状态会有PASS和FAIL两种。Average Transaction Response Time(平均事务响应时间)这是我们比较关心的数据之一，反映随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。如果和前面的用户负载生成图合并在一起看，就可以发现用户负载增加对系统事务响应时间的影响规律。在图511中可以看到响应时间是如何增长的，随着时间的推移响应时间逐渐变长，并且在不到8分钟的时候突然出现响应时间大幅下降的情况。图5。11 Average Transaction Response Time另外事务的响应时间也不应该超过用户的最大接受范围，否则会出现系统响应过慢的问题。Transactions per Second(每秒事务数)另一个关键数据是TPS吞吐量，该数据反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。在图512中上面的线是通过的事务，下面的线是失败的事务，这里可以看到系统的TPS随着时间的变化逐渐变大，而在不到10分钟的时候系统每秒可以处理1.9个事务。这里的最高值并不一定代表系统的最大处理能力，TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。而在4分钟以后开始出现少量的失败事务。图5.12 Transactions per SecondTransactionSummary(事务概要说明)该说明给出事务的Pass个数和Fail个数，了解负载的事务完成情况。通过的事务数越多，说明系统的处理能力越强；失败的事务越少，说明系统越可靠。在图513中可以看出，对于reg注册操作一共有613次操作成功，有6次失败。可以考虑结合前面的每秒错误数进一步分析为什么会出现6个注册错误，以及错误发生的时间和该时间产生错误的原因。图5.13 Transaction SummaryTransaction PerformanceS ummary(事务性能概要)这里会给出事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情况。在图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得到的，该图的线条越平稳，说明系统越稳定。在图5.15中可以看出在负载逐渐增加到5个用户时，事务的响应时间基本没有变化。而用户增加到15个开始，随着用户负载的增加响应时间也有较大的波动。 图5.15 Transaction Response Time Under LoadTransaction Response Time(Percentile)(事务响应时间的百分比)这里给出的是不同百分比下的事务响应时间范围，通过这个图可以了解有多少比例的事务发生在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。在图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(网页资源信息)这里给出的是对于Web操作的一些基本信息，这些信息在服务器端也能获得。当Controller的RunTime Setting中Preferences下的Generated Web performance graphs选项处于开启状态时，该图表才会出现。Hits per Second(每秒点击数)每秒点击数提供了当前负载中对系统所产生的点击量记录。每一次点击相当于对服务器发出了一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。在图5.18中可以看出随着时间的增加，每秒点击数在上升，最高达到78次s。图5.18 Hits per SecondThroughput(带宽使用)这里给出了在当前系统负载下所使用的带宽，该数据越小说明系统的带宽依赖越小，通过这个数据能确定是否出现了网络带宽的瓶颈(注意这里使用的单位是字节)。在图5.19中可以得到最高的带宽峰值是355000B，远远低于100Mb的局域网带宽上限，所以系统不存在带宽瓶颈。图5.19 ThroughputHTTP Responses per Second(每秒HTTP响应数)这里给出了每秒钟服务器返回各种状态的数目，该数值一般和每秒点击量相同。点击量是指客户端发出的请求数，而HTTP响应数是指服务器返回的响应数。如果服务器返回的响应数小于客户端发出的点击数，那么说明服务器无法应答超出负载的连接请求。在图5.20中可以看到最高峰时服务器每秒能返回接近75个HTTP 200 OK的状态。图5.20 HTTP responses per Second这个数据和前面的每秒点击数吻合，说明服务器能够对每一个客户端请求进行应答。Connections Per Second(每秒连接数)这里会给出两种不同状态的连接数，即中断的连接和新建的连接，方便用户了解当前每秒对服务器产生连接的数量。在图5.21中可以看到随着时间的推移，系统的连接数逐步上升，最高达到每秒4个连接。图5.21 Connections Per Second同时的连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止上升时，说明系统的连接池已满，无法连接更多的用户，通常这个时候服务器会返回504错误。可以通过修改服务器的最大连接数来解决该问题。5.3.5 Web Page Diagnostics(网页分析)当在场景中打开Diagnostics菜单下的Web Page Diagnostics功能，就能得到网页分析组图。通过这个图，可以对事务的组成进行抽丝剥茧的分析，得到组成这个页面的每一个请求时间分析，进一步了解响应时间中有关网络和服务器处理时间的分配关系。通过这个功能，可以实现对网站的前端性能分析，明确系统响应时间较长是由服务器端(后端)处理能力不足还是客户端连接到服务器的网络(前端)消耗导致的。更多内容参考6.1.5节中的前端性能分析。Web Page Diagnostics(网页分析)添加该图先会得到整个场景运行后虚拟用户访问的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秒上升到了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 Diagnostics Download TimeComponent(Over time)(各模块的时间变化)这里列出组成页面的每个元素，以及随着时间的变化所带来的响应时间变化。通过这个功能可以分析响应时间变长是因为页面生成慢，还是因为图片资源下载慢。在图5.25中可以发现随着时间的增加，首页的处理时间(最上面的一根线)从0.5秒上升到了最大值16秒，而注册用户响应时间几乎没有上升。图5.25 Web Page Diagnostics Component(Over Time)Download Time(Over time)(模块下载时间)这里提供了针对每个组成页面元素的时间组成部分分析，方便确认该元素的处理时间组成部分。在图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是指服务器对该页面的处理时间；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文件，将其中Breakdown-map表中的EventName的属性长度从50修改为255，在以后场景运行结果的报告中就可以显示最长为255字符的路径名称了。Page Download Time Breakdown(页面响应时间组成分析)这张图中显示了每个页面响应时间的组成分析，一个页面的响应时间一般由以下内容组成：Client Time客户端浏览器接收所需要使用的时间，可以不用考虑。Connections Time连接服务器所需要的时间，越小越好。DNS Resolution Time通过DNS服务器解析域名所需要的时间，解析受到DNS服务器的影响，越小越好。Error Time服务器返回错误响应时间，这个时间反映了服务器处理错误的速度，一般是Web服务器直接返回的，包含了网络时间和Web服务器返回错误的时间，该时间越小越好。First Buffer Time连接到服务器，服务器返回第一个字节所需要的时间，反映了系统对于正常请求的处理时间开销，包含网络时间和服务器正常处理的时间，该时间越小越好。FTP Authentication Time FTP认证时间，这是进行FTP登录等操作所需要消耗的认证时间，越短越好。Receive Time接受数据的时间，这个时间反映了带宽的大小，带宽越大，下载时间越短。SSL Handshaking TimeSSL加密握手的时间。而Analysis在这里会分析得到页面请求的组成比例图，便于分析页面时间浪费在哪些过程中。在图5.28中可以看到各个页面请求的响应时间组成情况，相对于00的首页请求，时间主要浪费在Client上。图5.28 Page Download Time BreakdownPage Download Time Breakdown(Over Time)(页面组成部分时间)这里提供了随着时间的变化所有请求的响应时间变化过程。这里会将整个负载过程中每个页面的每个时间组成部分都做成单独的时间线，以便分析在不同的时间点上组成该页面的各个请求时间是如何变化的。在图5.29中可以看到大多数页面的响应时间是比较稳定的，其中首页刷新变动较大。图529 Page Download Time Breakdown(Over Time)首先找到变化最明显或者响应时间最高的页面，随后再针对这个页面进行进一步的分析了解时间偏长或者变化较快的原因。Time to First Buffer Breakdown(页面请求组成时间)这里提供了组成页面时间请求的比例说明(客户端时间/服务器时间)，通过这个图，我们可以直观地了解到整个页面的处理是在服务器端消耗的时间长，还是在客户端消耗的时间长，从而分析得到系统的性能问题是在前端还是在后端。在图5.30中可以看出对于整个负载来说，网络或客户端的时间开销占了绝大多数。Time to First Buffer 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(网络监控)如果在Controller中添加了Network Delay Time监控后会出现该数据图。这个功能很好但并不是非常直观和方便，建议使用第三方专门的路由分析工具进行网络延迟和路径分析。Network Delay Time这里会给出从监控机至目标主机的平均网络延迟变化情况。在图532中可以看到网络延迟从240毫秒逐渐减少到26毫秒，最后上升到340毫秒。图532 Network Delay TimeNetwork Sub-Path Time这里给出从监控机至目标机各个网络路径的平均时间。当客户端在连接一个远程服务器时，路径并不是唯一的，受到路由器的路由选择，可能会选择不同的路径最终访问到服务器。在图533中列出了从监控服务器至目标服务器所经历的路径，以及每个路径上的网络延迟。图5.33 Network Sub-Path timeNetwork Segment Delay Time这里给出各个路径上的各个节点网络延迟情况。和图533不同的地方在于，这里给出的是路由器和路由器之间的网络延迟情况，针对连接而不是路径。图534中给出了路由器和路由器之间的网络延迟变化情况，以便于分析影响整个网络时间的原因及节点。图5.34 Network Segment Delay Time5.3.7 Resources(资源监控)资源包括很多种，在Analysis中监控的都是各种系统的计数器，这些计数器反映了系统中硬件或者软件的运行情况，通过它可以发现系统瓶颈。System Resources(系统资源)这里给出了对操作系统计数器的监控，列出了在负载过程中系统的各种资源数据是如何变化的，该图需要在场景中设置了对应系统的监控后才出现。Database Server Resources(数据库资源)这里给出了数据库的相关资源在负载过程中的变化情况。Web Server Resources(Web服务器资源)这里给出了Web服务器资源在负载过程中的变化情况。对于各种资源类的图来说，最困难的是理解各个计数器的含义。好比体检时会涉及血液化验，当一张血液化验单放在你面前时，普通用户是无法理解化验结果数据所反映的含义，现在通常会在化验报告单上简单介绍各个检查项目的含义，红细胞一般是在什么范围内，如果少了说明贫血。当进行性能瓶颈定位时，必须掌握常见各种计数器的含义和可能导致该结果的原因。计数器分析接着介绍一下各种在性能测试中需要监控的常见计数器名称及其含义和出现瓶颈的特征，供大家参考，更为具体的内容请参考各种应用的专用调优手册和计数器手册。如何获得硬件计数器瓶颈或者各种计数器瓶颈数据?可以先通过第三方工具对系统进行负载，监控在该负载下各个计数器的最高值是多少。当用LoadRunner进行负载时，如果该计数器达到该数据，则可以说明这个计数器出现了瓶颈。例如：通过磁盘工具对物理磁盘进行压力测试，在这个过程中可以监控到物理磁盘的读写速度计数器峰值为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 Service 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 WebLogic常用计数器5.4 图设置与操作在Analysis中经常需要和各种图打交道，那么我们需要对图的常见功能设置有所了解，在图上可以单击鼠标右键打开设置菜单，对图形进行一定的设置。SetFilterGroupBy(图的过滤规则设置)不同图的设置是不同的，主要是根据某些属性进行一定的过滤，来方便显示。SetGranularity(图的采样点间距)Analysis会自动根据场景运行的时间来设置数据采样点的间距，单位为秒。采样点越小，越能反映数据微小的变化；而采样点越大，则能反映系统在大趋势上的表现。View Cursor(打开鼠标指针)为鼠标在图中添加横向和纵向的标尺，方便了解鼠标所在位置的横坐标和纵坐标。View Raw Data(打开图所对应的数据)Comments(注释)在图中添加注释，便于说明某些问题。Clear Display Options(去掉所有的显示选项)该选项可以回到最原始的数据图模式，去掉所有的过滤和显示设置。Display Options(显示方式选项)设置图的显示方式，通过这个选项可以将图调整得更加好看，例如将图转化为3D模式或调整线条颜色及背景颜色等。5.4.1 Merge Graphs (合并图)当得到了相关图形，如何分析图和图之间的关系呢?MergeGraphs提供了一种将图和图合并的功能，通过这个功能可以直观地获得一个数据和另外一个数据的相互影响关系。在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方式通过这张图可以得到用户增长的过程是如何影响事务平均时间的，从而发现瓶颈出现的时间。TileTile的模式和Overlay的方式非常接近，只是将两张图的y轴分了上下两部分，不做重叠。将Running Vusers和Hits per Second进行Tile合并，如图538所示。图5.38 Tile的Merge方式通过这个合并，可以看到随着用户数量增加每秒点击量的变化过程，从而了解在当前负载下系统承受的点击量峰值。相对于Overlay方式，两张图的线条不会重叠在一起，看起来更加清楚。Correlate这个合并比较复杂，首先将主图的Y轴变为x轴，而被合并图的y轴依然保存为y轴，按照各图原本的时间关系进行合并形成新图。例如这里将Running Vusers和Transactions per Second两张图进行Correlate合并，如图539所示。图539Correlate的Merge方式系统将Running Vusers图的Y轴作为新图的x轴，将Transactions per Second图的y轴作为新图的y轴。在通过Correlate方式合并后的图中，可以更加清晰地看出用户变化导致处理能力的变化过程，斜率越大说明影响越大，方便快速定位在何种负载下系统响应时间能够稳定，而在何种负载下响应时间会大幅上升。通过这几种常见的Merge方法，可以将相关计数器得到的图进行合并分析，找出系统性能的瓶颈。由于系统瓶颈的定位需要大量的相关知识，对于一个初级性能测试工程师来说，并不要求有性能结果分析和性能瓶颈定位的能力。初级性能测试工程师可以将数据整理后提交给项目经理、网络或数据库管理员，让他们帮助你分析数据，并确认及完成性能调优工作。5.4.2 Auto Correlate(自动定位瓶颈)Auto Correlate提供了自动分析趋势影响的功能，通过它可以方便地找出哪些数据之间有明显的相互依赖性，通过图和图之间的关系确认系统资源和负载相互影响的关系。首先找到需要自动关联的图，右键打开Auto Correlate菜单。例如选择从Running Vusers图上做自动关联，如图540所示。弹出自动关联窗口，如图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分到6分是用户负载上升的阶段，这个阶段的特征就是增加。通过单击Next按钮可以切换到下一个特征，下一个特征是6分40秒至7分04秒的负载下降阶段，如图5.43所示。图5.43 Auto Correlate设置基于Feature特征的时间方式切换可以通过拖动图中的两根竖线来确定关联的范围或直接修改From后的时间来调整关联的范围。这样就确认了希望关联的时间范围，接着需要设置被关联的对象。2Correlation Options切换到Correlation Options标签，这里列出了所有和当前图可以进行关联的对象，默认选择了3个资源图，用户也可以自行设置需要关联的图，另外可以在Data Interval中设置数据点的间隔和Output中的输出情况，如图544所示。图5.44 Auto Correlate关联选项Data Interval是指自动关联的数据间隔，默认为5秒钟，也可以手工设定关联的数据间隔。间隔的时间设置越小得出的关联匹配度越精确。Output是对输出关联结果的设置，可以选择设置显示和被关联图匹配值最高的5个对象，也可以设置显示所有和被关联图匹配值大于50的对象。这里修改Select measurement categories选择对象为Hits per Second，其他选项保持默认值，确定后得到最终的自动关联结果，如图545所示。图5.45 Auto Correlate关联结果在结果中可以看到用户数量增加和每秒点击量的关系，这和做一个Run Vuser和Hits per Second计数器的overlay型的Merge操作没什么区别。但在面的数据中可以看到Collrelation Match数据项，这个项目是自动关联独有的。Correlation Match是指关联匹配度，该值反映了主数据和被关联数据的近似度。这里Hits per Second和被关联图Running Vuser的近似度为95，也就是说这两个数据变化的规律非常接近。通过单击右上角的Settings按钮可以重新设置自动关联选项。通过设置Correlation Options下的Data Interval和Output来改变自动关联的结果，找到和被关联对象波动接近的对象，进一步分析各个数据问的影响关系，从而确认瓶颈产生的原因。AutoCorrelation与Merge的区别在于：Merge不能“选定特定的时间进行切片”，