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

目录

第5章数据收集分析Analysis2

5.1新建Analysis分析2

5.2AnalysisSummary2

5.2.1AnalysisSummary（场景的摘要）3

5.2.2StatisticsSummary（场景状态的统计说明）3

5.2.35WorstTransaction（SLA失败事务）4

5.2.4ScenarioBehaviorOverTime（场景行为综述）5

5.2.5TransactionSummary（事务摘要）5

5.2.6ServiceLevelAgreementLegend（SLA图标说明）7

5.2.7HTTPResponsesSummary（HTTP响应摘要）7

5.3Graphs（数据图）8

5.3.1Vusers（虚拟用户状态）10

5.3.2Errors（错误统计）11

5.3.3Transactions（事务）11

5.3.4WebResources（网页资源信息）15

5.3.5WebPageDiagnostics（网页分析）17

5.3.6NetworkMonitor（网络监控）22

5.3.7Resources（资源监控）23

5.4图设置与操作34

5.4.1MergeGraphs（合并图）34

5.4.2AutoCorrelate（自动定位瓶颈）37

5.5TransactionReport（事务报告）40

5.6SLAReport（系统阈值监控报告）42

5.7ExternalMonitor•（外部监控数据导入）43

5.8Crosswithresult（跨脚本横向比较）45

5.9生成测试报告46

5.9.1创建HTML报告46

5.9.2创建Word报告47

5.9.3创建水晶报表47

小结49

第5章数据收集分析Analysis

通过场景完成负载后，我们完成了性能测试的执行过程，接着就是通过负载的结果来发

现和定位性能瓶颈。在这里Analysis就好比一个数据分析中心或数据仓库，它将场景运行中

所能得到的数据都整合在一起，能够对测试结果数据进行整理，并提供了一些方法可以进一

步对结果数据进行分析，从而找出系统的性能指标和可能的瓶颈，最终生成报告。

可以把Analysis看作一个股票分析软件，将股票的数据收集分析后生成K线图，而具体

说明了什么，还要依赖于分析者自身。使用Analysis进行性能测试结果的分析流程如图5.1

所示。

图5.1Analysis结果分析流程

5.1新建Analysis分析

导入场景数据生成Analysis报告的方式有以下三种：

1.当场景运行结束后在场景直接运行Results菜单下的AnalyzeResults命令进入

AnalysiSo

2.在Analysis中打开新建菜单，然后进入场景运行结束后的场景结果res目录，接着

Analysis会对整个场景数据进行整理，给出简明报告及相关图表。

3.在场景结果目录中直接双击MercuryLoadRunnerResult(.lrrj文件。

5.2AnalysisSummary

当Analysis导入场景数据后，首先映入眼帘的是统计表格AnalysisSummary场景摘要,

提供了对整个场景数据的简单报告。下面介绍一下该报告的各个组成部分。

5.2.1AnalysisSummary(场景的摘要)

AnalysisSummaryPeriod:23/03/200916:16:03-23/03/200916:27:07

ScenarioName:G:\scenario\analysis.lrs

ResultsinSession:G:\anlysis\res00\res00.1rr

Duration:11minutesand4seconds.

这里给出了场景的摘要(AnalysisSummary),包括以下内容：

•Period：场景运行的起止时间

•ScenarioName：场景名称

,ResultsinSession：场景运行的结果目录

,Duration：场景运行的时间

通过场景摘要可以了解场景执行的基础信息。

5.2.2StatisticsSummary(场景状态的统计说明)

StatisticsSummary

MaximumRunningVusers:50

TotalThroughput(bytes):Q-130,405,783

AverageThroughput(bytes/second):S196,099

TotalHits:Q23,504

AverageHitsperSecond:635.344ViewHTTPResponsesSummary

场景状态的统计说明(StatisticsSummary)包含以下内容：

•MaximumRunningVusers：场景最大用户数

•TotalThroughput(bytes)：总带宽流量

,AverageThroughput(bytes/second)：平均每秒带宽流量

,TotalHits：总点击数

•AverageHitsperSecond：平均每秒点击数

单击ViewHTTPResponsesSummary选项可以切换到报告的最下端查看HTTP请求的统

计。在每项数据标题和数据中，还会看到一个小的球形图标囊，单击后会进入SLA分析报告。

5.2.35WorstTransaction（SLA失败事务）

5WorstTransactions

FailureRatio[%]FailureValue[%]

TransactionName,..…、

_________________________(exceededUme/transactionduration)K(responsetime/SLA)

-reg100Infinity___________

TimeIntervalAvgexceedingratioMaxexceedingratio

00:00:25-00:11:05InfinityInfinity

这里列出了对5大失败事务的统计，只有当在Controller或Analysis中定义了SLAstatus

determinedattimeintervalsoveratimeline监控时才会出现该报告。

,TransactionName(事务名)。

,FailureRatio[%](exceededtime/transactionduration)失败率(超标次数/事务持续时间)。

该值反映了在所有事务中有百分之多少的事务是无法达到SLA基准值。

,FailureValue[%](responsetime/SLA)失败率(响应时间/SLA)。

该值反映了在整个场景运行下，SLA的定义标准值与实际事务值超标的平均百分比，也

就是说平均算下来真实的响应时间和定义的阈值误差百分比。

通过这行报告，我们可以清晰地了解该事务有多少是无法达到SLA标准的，以及无法达

到标准的事务与SLA的误差范围是多少。

单击事务名前的加号还能列出该事务在SLA定义的持续时间下平均误差比例和最大误

差比例。Analysis会根据SLA中的定义分析事务的通过率，在这个场景结果中，所有的事务

响应时间都在SLA监控值以外，所以结果为Infinity全部超标。

分析的失败事务数可以在Tools菜单下Options的General标签中进行设置，默认为5

个事务，如图5.2所示。

SummaryReport

JransacbonPwcenirfe

[5日worsttoamacbora

图5.2SummaryReport设置

5.2.4ScenarioBehaviorOverTime（场景行为综述）

ScenarioBehaviorOverTime

TheSLAstatusofthefollowingmeasurementsdisplayedovertime.Youcanselectaspecific

timerangeforeachtransactioninordertoanalyzethetimerange.

MeasurementNameTimeRanges

ApplicationUnderTestOOOOOOOOOOOOOOOOOO

Errors

l08ll8l1lil0l8l8l0lllllllll

0:0

20:0

一00:888S8SS

80840ss

::2d3:4修O金修修$O

:一:

83s0425O'O'OCOC2o

550055g0二5425t3oK二5

这里列出了在场景中定义的事务在各个时间点上的SLA情况，背景中的x表示在这个时

间点上事务没有达到SLA的指标。而上面的ApplicationUnderTestErrors显示了在每个时间

段上的错误数目。

5.2.5TransactionSummary（事务摘要）

TransactionSummary

Transactions:TotalPassed:613TotalFailed:6TotalStopped:0AverageResponseTime

TransactionSLAStd.90

MinimumAverageMaximumPassFailStop

NameStatusDeviationPercent

reg2.5552.9243.8970.4083.60361360

这里首先给出的是场景中所有事务的情况说明：

•TotalPassed（事务的总通过数）

•TotalFailed（事务的总失败数）

,TotalStoppecK事务的总停止数）

AverageResponseTime是一个链接，可以打开事务平均响应时间图表。

下面给出每个具体事务的情况列表，可以看到以下数据项:

,TransactionName（事务名）

•SLAStatus（SLA状态）：在SLA的指标测试中最终结果是通过还是失败

•Minimum（事务最小时间）

•Average（事务平均时间）

,Maximum（事务最大时间）

•Std.Deviation（标准方差）

标准方差，这个数据是描述采样数据离散状态很重要的指标，它又分为以下两种：

1.给定样本标准方差，它是估算给定样本而不是整个样本的标准方差（也就是样本中的

一部分），计算公式如下：

Vn（n-l）

其中X代表平均值，，n代表取样个数。n-l是统计学上的常用做法，主要考虑到采样量

越大，越能反映真实的情况。

2.总体样本标准方差，它是估算整个采样样本的标准方差（注意是整个采样数据而不是

部分），计算公式如下：

s处

当采样数据足够大的时候，上述两种计算方式得出的偏差相差很小。

标准方差相对于平均值越大，说明数据越离散，则分布状态相对于平均值波动很大；标

准方差相对于平均值越小，说明数据分布越集中，曲线也越平稳。在采样值服从正态分布的

条件下通过上面的指标结合平均值、最大值、最小值，可以比较清楚地知道采样数据的分布

状态及其是否有较大的波动。

,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,所以90Percent的结果就是9。

它的主要作用就是来了解在某个响应时间内有百分之多少的用户。当然这个90%是可调整

的，在Analysis中通过View菜单中SummaryFilter下的TransactionPercentile选项来调整。

•Pass（事务通过数）

•Fail（事务失败数）

•Stop（事务停止数）

5.2.6ServiceLevelAgreementLegend（SLA图标说明）

ServiceLevelAgreementLegend:。Pass，FaildNoData

图标为灰色带减号的Ql为N。Data,说明在SLA中未对这个数据项进行监控，没有数

据；图标为红色带叉的.为Fail,说明在SLA中定义了该项的数据监控，但该数据未能达

到期望的阈值；图片为绿色带钩的.为Pass,说明在SLA中定义了该项的数据监控，该数

据达到了的期望阈值。

5.2.7HTTPResponsesSummary（HTTP响应摘要）

HTTPResponsesSummary

HTTPResponsesTotalPersecond_____________

HTTP_20023,50435.344___________________

这里给出了服务器返回的状态。

•服务器返回HTTP请求状态（HTTPResponses,具体的服务器返回状态码见附录A）

•HTTP请求返回次数（Total）

,每秒请求数（Persecond）

通过AnalysisSummary可以对整个性能测试的结果有一个直观的介绍，特别是通过SLA

的数据可以直观地了解在整个负载中系统的性能指标是否满足阈值，除此以外设置的事务响

应时间数据也会显示。Analysis保存后会生成MercuryLoadRunnerAnalysisSession（.Ira）文件。

通过File菜单下的SessionInformation功能可以了解该Session文件的属性，而File菜单下的

ViewScenarioRunTimeSettings功能可以查看该报告场景的运行设置。当粗略了解了整个场

景的情况后，根据场景执行前的目标，可以对整个系统的性能有一定的了解，接着需要对关

心的数据进行进一步的了解和分析。

5.3Graphs（数据图）

在场景运行时可以看到一些图，这些图将场景中的数据转化为折线图，方便我们了解当

前该数据的状态。在默认情况下，Analysis会自动打开如图5.3所示的几张图。

这是系统最基本的几个图，这些图反映了在不同时间段相关计数器的数据变化情况，可

以通过在Graphs上右键菜单中的AddNewGraphs命令完成添加图的操作，添加后弹出

Graphs管理器，如图5.4所示。

OpenaNewGraph窗口中，可以得到所有能添加的计数器图形，勾选左下角的Display

onlygraphscontainingdata选项可以隐藏没有数据的计数器，有数据的计数器则会以蓝色显

示在左侧区域。而选中具体的图，在右侧的GraphDescription中会有更加详细的介绍。在

GraphProperties中还可以对生成的图表进行一定的属性设置，例如生成的图是使用整个场

景的时间还是其中的某一部分时间。

门Graphs

£RunningVusers

£HitsperSecond

威Ihrou^iput

£TransactionSummary

£AverageTransactionResponseTime

图5.3默认情况下系统打开的Graphs图5.4数据图管理器

注意

在Analysis9.1中由系统自动打开的图中存在一定的数据错误，例如平均事

务响应时间图中的标准方差数据就会和AnalysisSummary中的数据存在偏差，这里

只需要通过AddGraph再添加一次即可解决该问题。

\_______________________________________________________________________________________________________J

对于任意一张图，都可以在右侧看到有2个功能：UserNotes和RawData。UserNotes

提供对某张图进行文字描述的功能；RawData是将生成该图的数据列出。

在RawData中单击Clicktoretrieverawdata,会弹出RawData窗口，设置场景持续的时

间，确认后可以得到该时间段内组成该图的所有数据，如图5.5所示。

图5.5RawData数据表

这里可以将数据另存为Excel文件，再通过第三方工具进行分析。例如将导出的场景数

据使用SPSS工具进行进一步的数学分析。在图的下方，Legend窗口会显示图中对象说明信

息以及相关数据，如图5.6所示。

通过对显示对象的一些设置，可以得到更好的显示效果。在Legend窗口中单击鼠标右

键，弹出菜单如图5.7所示。

图5.6Legend图中对象数据说明

覆Show

工Hide

仁Showonlyselected

7ShowaH

庄Configuremeasurements.

0meawemcntde^a

•Animateselectedline

AutoCorrelate一

$nrtbythiscolumn

Conflyxr.c

图5.7Legend设置选项菜单

可以通过Show/Hide/Showonlyselected/Showall命令设置所需要选的项目，也可以通过

Configuremeasurements/Showmeasurementdescription命令设置线条的颜色及显示方式。

Animateselectedline选项可以在切换线条时获得更加明显的动画效果，AutoCorrelate提供

了对所选对象的自动关联操作（参考5.4.2节），而在Configurecolumns中可以设置在Legend

中显示哪些属性名。

每张图都代表了场景运行中监控到的数据变化趋势,所以看懂每一张图的含义是性能分

析的第一步，接着我们来介绍一些常见图的含义。

5.3.1Vusers（虚拟用户状态）

Vusers用户状态计数器组提供了产生负载的虚拟用户运行状态的相关信息，可以帮助我

们了解负载生成的过程。

RunningVusers（负载过程中的虚拟用户运行情况）

该图可以反映系统形成负载的过程，随着时间的推移，虚拟用户数是如何变化的。

在图5.8中可以看到用户在9分钟左右到达了负载峰值50个虚拟用户，负载的生成是

大约每分钟增加5个用户，峰值负载持续1分30秒。

RunningVusers

S50

J

e

s40

n

A

J

。30.

」

20-

qa>

u

J

n10-

N

0100020003:000400050006000700080009:00100011(X

Elapsedscenariotimemm:ss

图5.8RunningVusers

Rendezvous（负载过程中集合点下的虚拟用户数）

当场景中设置了集合点后会出现这张图，该图反映了随着时间的推移各个时间点上并发

用户的数目，方便我们了解并发用户数的变化情况。在图5.9中可以看到刚开始的7分钟

内，负载的并发用户都是1个，而后面变化为2个用户并发。

JSRendezvous

s8

>n

P

8

S

&

8

a

J

O

」

qQ.

uL

Nn

Elapsedscenariotimemmss

图5.9Rendezvous

5.3.2Errors（错误统计）

当场景在运行中出现错误时，错误信息将会被保存在该计数器组中，通过Error信息可

以了解错误产生的时间和错误的类型，帮助我们定位产生错误的原因。

ErrorsperSecond（每秒错误数）

通过每秒错误数可以了解在每个时间点上错误产生的数目，该数据越小越好。通过这个

图可以了解错误随负载的变化情况，定位何时系统在负载下开始不稳定甚至出错，配合系统

日志可以定位产生错误的原因。

在图5.10中可以看到场景在37秒的时候出现了一次错误。

ErrorsperSecond

1■

e

o

t

山

J

O

J

B

q

E

n

N

图5.10ErrorsperSecond

5.3.3Transactions（事务）

这里给出了所有和事务相关的数据统计,方便了解被测系统业务处理的响应时间和吞吐

量，在3.9节中介绍了系统事务默认有3种状态PASS、FAIL、STOP,如果是手工事务那么

状态会有PASS和FAIL两种。

AverageTransactionResponseTime（平均事务响应时间）

这是我们比较关心的数据之一，反映随着时间的变化事务响应时间的变化情况，时间越

小说明处理的速度越快。如果和前面的用户负载生成图合并在一起看，就可以发现用户负载

增加对系统事务响应时间的影响规律。

在图5.11中可以看到响应时间是如何增长的，随着时间的推移响应时间逐渐变长，并

且在不到8分钟的时候突然出现响应时间大幅下降的情况。

,

问力的里加败越以和

的能统这增失数可间

。

慢大系的的务。时

过最到务载量事败的

应的看事负少的失生

C响以个着现过次发

1务9

1统业可.随出通6误

01

0系理里理会始8。有错

00，

1现处这处也开1况及

0出能，，后0情功以

0以0:。，

9e会务响以9成成

0m内可0靠误

0i则间事影钟0完作

0T秒0_可错

e6se否的的分8s务操

0ss时每0s

m，d越册

i.nn一败载40n事次

T0ro围统0m统

0mp失负在o的3注

e7s同系7mc1

s0ee范d0ee系6个

nm在是到而nS载

o0iR受候o0mir明6

0t统线受。c:0te负有

p6on接时e6现

s0no0op说共

eait系的会降Sns解

R0nc大的Sr0an，出

0ea了面P下e0n了一

n5cs最钟p6eoi少会

o0s下T所0ct，作

tin映*sc么

cda的分，n0a越

0er反，有0ds数操

a0T户0力io-e什

s4stMsn务

n0pe）据务1会cpa个册

aalg用。能Sar）l事为

r0a数事到w0lTi注

T0Er过数强理Pn0E明a的析

3e该的不Ta3Fg

e0v超务，越处，r02说败e分

gA过在T01和r

a0事0:.

r0该量力大后25要失于步

e2通而0数

v01应秒吐能最期概；一

A1是，0K个对

0。不每（吞理的忙:0务强进

0线大1s，

15也dS统0s数

0nP处的变繁事（a越出

图间coT统系入yP力看误。

----e面渐r

a642386时S是系表进510a的能以错因

333322上逐.S

应r据代1Om务

e明中化统m理可秒原

响p数定u事

)agls说2变系=oesuss处中每的

puoo8s,esuodsaa的n键，一Su。jon出3

o1的当o的1的误

务ti关高.不，it给统面错

c5间c.

事as个越时并加as明系5前生

外n一据图值增n说明图合产

ra着ar

另T另数在随高渐。T该说在结间

。个S最逐务，虑时

P

题这T的而事多考该

TransactionSummary

图5.13TransactionSummary

TransactionPerformancesummary（事务性能概要）

这里会给出事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情

况。在图5.14中可以看到reg这个事务最大时间为3.897s,最小时间为2.555s,平均时间为

2.924so柱状图的落差越小说明响应时间的波动较小，如果落差很大，那么说明系统不够稳

定。

r

o

uTransactionPerformanceSummary

t

e

®

s

u

g.8

8

(zU

.2O

B

S

Ur”

0Transactionname

图5.14TransactionPerformanceSummary

TransactionResponseTimeUnderLoad（在用户负载下事务响应时间）

这里给出了在负载用户增长的过程中响应时间的变化情况，其实这张图也是将Vusers

和AverageTransactionResponseTime图做了一个CorrelateMerge得到的，该图的线条越平

稳，说明系统越稳定。在图5.15中可以看出在负载逐渐增加到5个用户时，事务的响应时

间基本没有变化。而用户增加到15个开始，随着用户负载的增加响应时间也有较大的波动。

8

£

一1

s

s

u

o

d

s

8

a

§2>

a

&

图5.15TransactionResponseTimeUnderLoad

TransactionResponseTime(Percentile)(事务响应时间的百分比)

这里给出的是不同百分比下的事务响应时间范围，通过这个图可以了解有多少比例的事

务发生在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。

在图5.16中可以看到60%的事务是在3秒内。

IransactionResponseTime(Percentile)

2040608010C

Percentoftransactions

图5.16TransactionResponseTime(Percentile)

TransactionResponseTime(Distribution乂每个时间段上的事务数)

该图给出的是在每个时间段上的事务个数，响应时间较小的分类下的事务数越多越好。

从图5.17中可以看到在所有的事务中，有391个事务的响应时间最接近2秒，而有222个

事务的响应时间最接近3秒。

TransactionResponseTime(Dtetribution)

s

u

o

U

B

S

U

e

二

j

o

o

q

E

n

N

23

TransactionResponsetime(roundeddowntothenearestsecond)

图5.17TransactionResponseTime(Distribution)

5.3.4WebResources（网页资源信息）

这里给出的是对于Web操作的一些基本信息，这些信息在服务器端也能获得。当

Controller的RunTimeSetting中Preferences下的GeneratedWebperformancegraphs选项处

于开启状态时，该图表才会出现。

HitsperSecond（每秒点击数）

每秒点击数提供了