搜索
LR结果分析通过场景完成负载后，我们完成了性能测试的执行过程，接着就是通过负载的结果来发现和定位性能瓶颈。在这里Analysis就好比一个数据分析中心或数据仓库，它将场景运行中所能得到的数据都整合在一起，能够对测试结果数据进行整理，并提供了一些方法可愿意进一步对结果数据进行分析，从而找出系统的性能指标和可能的瓶颈，最终生成报告。可以把Analysis看作一个股票分析软件，将股票的数据收集分析后生成K线图，而具体说明了什么，还要依赖于分析者自身。1.1新建Analysis分析导入场景数据生成Analysis报告的方式有一下三种：1.当场景运行结束后在场景直接运行Results菜单下的AnalyzeResults命令进入Analysis。2.在Analysis中打开新建菜单，然后进入场景运行结束后的场景结果res目录，接着Analysis会对整个场景数据进行整理，给出简明报告及相关图表。3.在场景结果目录中直接双击MercuryLoadRunnerResult（.lrr）文件。1.2AnalysisSummary当Analysis导入场景数据后，首先看到的是统计表格AnalysisSummary场景摘要，提供了对整个场景数据的简单报告。1.2.1AnalysisSummary（场景摘要）这里给出了场景的摘要，包括以下内容：Period：场景运行的起止时间ScenarioName：场景名称ResultsinScenario：场景运行的结果目录Duration：场景运行的时间通过场景摘要可以了解场景执行的基本信息。1.2.2StatisticsSummary（场景状态的统计说明）场景状态的统计说明包含以下内容：MacimumRunningVusers：场景最大用户数ToalThtoughput：总带宽流量AverageThtoughput：平均每秒带宽流量TotalHits：总点击数AverageHitsperSecond：平均每秒点击数单击ViewHTTPResponsesSummary选项可以切换到报告的最下端查看HTTP请求的统计。1.2.3ScenarioBehaviorOverTime（场景行为综述）这里列出了在场景中定义的事务在各个时间点上的错误数。1.2.4TansactionSummary（事务摘要）这里首先给出的是场景中所有事务的情况说明：TotalPassed（事物的总通过数）TotalFaild（事物的总失败数）TotalStopped（事物的总停止数）AverageResponseTime是一个链接，可以打开事务平均响应时间图表。下面给出每个具体事务的情况列表，可以看到以下数据项：TansactionName事务名Minimum事务最小时间Average事务平均时间Maximum事务最大时间Std.Deviation标准方差标准方差，这个数据是描述采样数据离散状态很重要的指标，它又分为以下两种：1.给定样本标准方差，它是估算给定样本而不是整个样本的标准方差，计算公式如下：)1()(2nnxxS主要考虑到采样量越大，越能反映真实的情况2.总体样本标准方差，它是估算整个采样样本的标准方差，计算公式如下：22)(nxxS当采样数据足够大的时候，上述两种计算方式得出的偏差相差很小。标准方差相对与平均值越大，说明数据越离散，则分布状态相对于平均值波动很大；标准方差相对于平均值越小，说明数据分布越集中，曲线也越平稳。在性爱样值服从正态分布的条件下通过上面的指标结合平均值、最大值、最小值，可以比较清楚地知道采样数据的分布状态及其是否有较大的波动。90Percent（用户感受百分比）这个值说明的采样数据中有90％的数据比它小，有10％的数据比它大。它的主要作用就是来了解在某个响应时间内有百分之多少的用户。1.2.5HTTPResponsesSummary（HTTP响应摘要）这里给出了服务器返回的状态服务器返回HTTP请求状态HTTP请求返回次数每秒请求数通过AnalysisSummary可以对整个性能测试的结果有一个直观的介绍，特别是设置的事务响应时间数据也会显示。Analysis保存后会生成MercuryLoadRunnerAnalysisSession文件。通过File菜单下的SessionInfomation功能可以了解该Session文件的属性，而File菜单下的ViewScenarioRunTimeSettings功能可以查看该报告场景的运行设置。当粗略了解了整个场景的情况后，根据场景之前的目标，可以对整个系统的性能有一定的了解，接着需要对关心的数据进一步的了解和分析。1.3Graphs（数据图）在场景运行时可以看到一些图，这些图将场景中的数据转化为折线图，方便我们了解当前该数据的状态。在默认情况下，Analysis会自动打开以下几张图。这是系统最基本的几个图，这些图反映了在不同时间段相关计数器的数据变化情况，可以通过在Graphs上右键菜单中的AddNewGraphs命令完成添加图的操作，添加后弹出Graphs管理器。在OpenaNewGraph窗口中，可以得到所有能添加的计数器图形，勾选左下角的Displayonlygraphscontainingdata选项可以隐藏没有数据的计数器，有数据的计数器则会以蓝色显示在左侧区域。而选中具体的图，在右侧的GraphDescription中会有更加详细的介绍。在GraphsProperties中还可以对生成的图表进行一定的属性设置，例如生成的图是使用整个场景的时间还是其中的某一部分时间。在图的下方，Legend窗口会显示途中对象说明信息以及相关数据。1.3.1VusersVusers用户状态计数器组提供了产生负载的虚拟用户运行转改的相关信息，可以帮助我们了解负载生成的过程。RunningVusers该图可以反映系统形成负载的过程，随着时间的退役，虚拟用户数是如何变化的。Rendezvous当场景中设置了集合点后会出现这张图，该图反映了随着时间的推移各个时间点上并发用户的数目，方便我们了解并发用户数的变化情况。1.3.2Errors当场景在运行中出现错误时，错误信息将会被保存在该计数器组中，通过Error信息可以了解错误产生的时间和错误的类型，帮助我们定位产生错误的原因。ErrorsperSecond通过每秒错误数可以了解在每个时间点上错误产生的数目，该数据越小越好。通过这个图可以了解错误随负载的变化情况，定位何时系统在负载下开始不稳定甚至出错，配合系统日志可以定位产生错误的原因。1.3.3Tansactions这里给出了所有和事务相关的数据统计，方便了解被测系统业务处理的响应时间和吞吐量。AverageTansactionResponseTime这是我们比较关心的数据之一，反映随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。如果和前面的用户负载生成图合并在一起看，就可以发现用户负载增加对系统事务响应时间的影响规律。响应时间通常随着时间的推移，响应时间逐渐变长。事务的响应时间不应该超过用户的最大接受范围，否则会出现系统响应过慢的问题。TansactionsperSecond另一个关键数据是TPS吞吐量，该数据反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。TansactionSummary该图给出事务的Pass和Fail的个数，了解负载的事务完成情况。通过的事务越多，说明系统的处理能力越强；失败的事务越少，说明系统越可靠。可以考虑结合前面的每秒错误数进一步分析为什么会出现错误，以及错误发生的时间和该时间产生错误的原因。TansactionPerformanceSummary这里会给出事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情况。柱状图的落差越小说明响应时间的波动较小，如果落差很大，那么说明系统不够稳定。TansactionResponseTimeUnderLoad这里给出了在负载用户增长的过程中响应时间的变化情况，其实这张图也是将Vusers和AverageTansactionResponseTime图做了一个CorrelateMerge得到的，该图的线条越平稳，说明系统越稳定。TansactionResponseTime（Percentile）这里给出的是不同百分比下的事务响应时间范围，通过这个图可以了解有多少比例的事务发生在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。TansactionResponseTime（Distribution）该图给出的是每个时间段上的事务个数，响应时间较小的分类下的事务数越多越好。1.3.4WebResources（网页资源信息）这里给出的是对于Web操作的一些基本信息，这些信息在服务器端也能获得。当Controller的RunTimeSetting中的Preferences下的GeneratedWebperformancegraphs选项处于开启状态时，该图表才会出现。HitsperSecond每秒点击数提供了当前负载中对系统所产生的点击量记录。每一次点击相当于对服务器发出了一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。Throughput这里给出了在当前系统负载下所使用的带宽，该数据越小说明系统带宽依赖越小，通过这个数据能确定是否出现了网络带宽瓶颈（注意这里实用的单位是字节）。HTTPResponsesperSecond这里给出了每秒钟服务器返回各种状态的数目，该数值一般和每秒点击量相同。点击量是指客户端发出的请求数，而HTTP响应数是指服务器返回的响应数。如果服务器返回的响应数小于客户端发出的点击数，那么说明服务器应答超出负载的连接请求。这个数据如果与前面的每秒点击数吻合，说明服务器能够对每一个客户端请求进行应答。ConnectionsPerSecond这里会给出两种不同状态的连接数，即中断的连接和新建的连接，方便用户了解当前每秒对服务器产生连接的数量。同时的连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止上升时，说明系统的连接池已满，无法连接更多的用户，通常这个时候服务器会返回504错误。可以通过修改服务器的最大连接数来解决该问题。1.3.5WebPageDiagnostics当在场景中打开Diagnostics菜单下的WebPageDiagnostics功能，就能得到网页分析组图。通过这个图，可以对事务的组成进行抽丝剥茧的分析，得到组成这个页面的每一个请求时间分析，进一步了解响应时间中有关网络和服务器处理时间的分配关系。通过这个功能，可以实现对网站的前端性能分析，明确系统响应时间较长是由服务器端处理能力不足还是客户端连接到服务器的网络消耗导致的。WebPageDiagnostics添加给图先会得到整个场景运行后虚拟用户访问的Page列表，也就是所有页面下载时间列表。然后通过SelectPagetoBreakDown命令选择具体的Page来获得每个请求的相关详细信息。在Diagnosticsoptions选项中提供了以下4大块功能。DownloadTime这里可以得到组成页面的每个请求下载时间。Component（Overtime）这里列出组成页面的每个元素，以及随着时间的变化所带来的响应时间变化。通过这个功能可以分析响应时间变长是因为页面生成慢，还是因为图片资源下载慢。DownloadTime（Overtime）这里提供了针对每个组成页面元素的时间组成部分分析，方便确认该元素的处理时间组成部分。TimetoFirstBuffer（Overtime）这里会列出该元素所使用的时间分配比例，是受NetworkTime影响的多还是ServerTime影响的多。ServerTime是指服务器对该页面的处理时间，NetworkTime是指网络上的时间开销。通过分析这4个分析图，我们可以了解到对于事务的响应时间来说，服务器的处理时间不是组成响应时间的主要部分，而网络问题通常会占用超过