LoadRunner性能测试指标参考Word格式.docx

LoadRunner性能测试指标参考Word格式.docx

《LoadRunner性能测试指标参考Word格式.docx》由会员分享，可在线阅读，更多相关《LoadRunner性能测试指标参考Word格式.docx（28页珍藏版）》请在冰点文库上搜索。

如果服务器如预期的一样执行，那么呑吐量会随着它每秒的点击量而增加。

如果点击的次数增加而呑吐量恒定或减少，就说明服务器无法执行增加的请求（每秒点击率），结果就是事务响应时间的增加。

2Vuser图

在负载测试场景执行期间，Vuser会在执行事务时生成数据。

通过Vuser图您可以

确定场景执行期间Vuser的整体运行情况。

这些图会显示Vuser状态、已完成脚

本的Vuser数以及集合统计信息。

将这些图与事务图相结合可以确定Vuser数目

对事务响应时间的影响。

2.1“运行Vuser”图（RunningVusers）

1“运行Vuser”图显示测试期间每秒钟执行Vuser脚本的Vuser数及其状态。

此图

2对于确定任意给定时刻服务器上的Vuser负载非常有用。

默认情况下，此图仅显

3示处于运行状态的Vuser。

要查看其他Vuser状态，请将筛选条件设置为所需的状

4态。

2.2“集合”图（Rendezvous）

“集合”图显示在集合点处释放Vuser的时间以及每个点释放的Vuser数。

此图有助于了解事务性能时间。

通过对比“集合”图和“平均事务响应时间”

图，您可以看到由集合产生的负载峰值如何影响事务时间。

3错误图

3.1“每秒错误数（按描述）”图（ErrorStatistics）

“每秒错误数（按描述）”图显示负载测试场景运行期间每秒所发生错误的平均数（按错误描述分组）。

在图例中显示错误描述。

错误数越小越好，通过错误数可以定位系统在负载情况下，什么时候出错，查找出系统错误的原因。

常见错误提示分析：

1、Error:

Failedtoconnecttoserver“10.10.10.30:

8080″:

[10060]Connection

Error:

timedoutError:

Server“10.10.10.30″hasshutdowntheconnectionprematurely

分析：

A、应用服务死掉。

小用户时：

程序上的问题。

程序上处理数据库的问题

B、应用服务没有死

应用服务参数设置问题

例：

在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。

如果连接时收到connectionrefused消息，说明应提高该值，每次增加25％。

C、数据库的连接

在应用服务的性能参数可能太小了；

或数据库启动的最大连接数（跟硬件的内存有关）

2、Error:

Pagedownloadtimeout（120seconds）hasexpired

可能是以下原因造成

A、应用服务参数设置太大导致服务器的瓶颈

B、页面中图片太多

C、在程序处理表的时候检查字段太多

4事务图

4.1“平均事务响应时间”图（AverageTransactionResponseTime）

“平均事务响应时间”图显示负载测试场景运行期间每秒内用于执行事务的平均时间。

X轴表示自场景开始运行以来经过的时间。

Y轴表示每个事务的平均响应时间（秒）。

响应时间标准可参考国外的3/5/10原则（见术语章节-响应时间部分）。

平均事务响应时间会随着负载用户数的增加而增加。

平均事务响应时间在规定时间内越平稳越好。

响应时间出现波峰越多系统越不稳定。

4.2“负载下的事务响应时间”图（RunningVuser–AverageTransactionResponseTime）

“负载下的事务响应时间”图是“运行Vuser”图与“平均事务响应时间”图的组合，显示负载测试场景运行期间相对于任何给定时间点运行的Vuser数目的事务时间。

此图有助于查看Vuser负载对性能时间的总体影响，在分析逐渐加压的场景时最有用。

在Analysis的“运行Vuser”图-点击右键–选择“合并图表”（MergeGraphs）-在图表选项，选择“平均事务响应时间”图；

在合并类型选项，选择“Correlate”。

即可生成“负载下的事务响应时间”图。

图4-1“负载下的事务响应时间”图

4.3“页面细分”图（WebPageDiagnostics图）

“平均事务响应时间”图点击右键选择“ShowTransactionBreakdownTree”-在“BreakdownTree”选择一要查看“页面细分”图的事务-点击右键，选择“WebPageDiagnosticsforXX（事务）”，生成“页面细分”图。

注：

生成“页面细分”图的前提是，执行场景时，需要在Controller–Diagnostics–Configuration，勾上“WebPageDiagnostics”。

正常的从浏览器发送一个请求到最后显示，整个过程由以下时间片组成，如图4-2所示。

图4-2网络时间解析图

1）DNS解释时间（DNSResolution）

浏览器向服务器发送一个请求，一般情况下，客户端的请求首先被发送到DNS服务器上，通过域名解析，将DNS名解析为IP地址。

其中域名解析的时间就是DNS解析时间（DNSResolution）。

通过这个时间可以确定DNS服务器或DNS服务器的配置是否有问题。

如果DNS服务器运行情况良好，这个时间会比较小。

2）连接时间（Connection）

DNS解析完成后，请求被送到Web服务器，之后浏览器与Web服务器之间需要建立一个初始化连接。

建立连接的过程就是连接时间（Connection）。

通过这个时间就可以判断网络的情况，也可以判断Web服务器是否能够响应这个请求。

如果正常，这个时间会比较小。

3）第一个字节时间（FirstBuffer）

建立连接后，Web服务器发出第一个数据包，经过网络传输到客户端，浏览器成功接收到第一个字节的时间就是FirstBuffer的时间。

这个度量时间不仅可以表示Web服务器的延迟时间，还可以表示网络反应时间。

4）接收时间（Receive）

从浏览器接收第一个字节起，知道成功收到最后一个字节，下载完成为止。

5）ClientTime:

请求在客户端浏览器延迟时间，可能是由于客户端浏览器的ThinkTime或者客户端其他方面引起的延迟；

6）ErrorTime：

从发送一个HTTP请求，到Web服务器发送回一个HTTP错误信息所需要的时间。

4.4“每秒事务数”（Transactionspersecond简称：

TPS）

性能又一关键数据指标TPS，该数据反映了系统在同一时间内处理业务最大能力，这个数据越高，说明系统处理能力越强。

当然TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙的时候，TPS会下降。

当TPS下降要查看是否服务处理能力下载，是否出现事务等待排队，导致响应时间的增加等情，结合响应时间指标和服务器指标分析。

5Web资源图

5.1“每秒点击次数”图（HitsperSecond）

“每秒点击次数”图显示负载测试场景运行期间的每一秒内Vuser向Web服务器发出的HTTP请求数。

此图可帮助您根据点击次数对Vuser生成的负载量进行评估。

可以将此图与“平均事务响应时间”、“负载用户数”图进行比较，查看点击次数对事务性能的影响。

点击随负载用户增加而增加，点击次数越多越好。

点击数增加，响应时间增加超出规定时间，说明系统服务器排队处理事务，需要关注服务器的磁盘、内存、和CPU使用情况确定系统性能问题。

5.2“吞吐量”图（Throughput）

“吞吐量”图显示在负载测试场景运行的每一秒，服务器上的吞吐量。

吞吐量以字节为单位，表示Vuser在任意给定的一秒内从服务器接收的数据量。

此图可帮助您根据服务器吞吐量对Vuser生成的负载量进行评估。

可以将此图与“平均事务响应时间”图进行比较，查看吞吐量对事务性能的影响。

吞吐量会随负载用户增加受影响。

当负载用户数量增加，吞吐量增加，响应时间在规定范围，说明系统稳定。

当负载用户增加，吞吐量增加或者下降，响应时间超出规定范围，说明系统有问题或者服务处理能力下载。

6系统资源图

LoadRunner可监控Windows资源、UNIX资源。

下面说下UNIX资源的三个重要的指标。

6.1LoadRunner下监控的UNIX资源指标

6.1.1平均负载（Averageload）

上一分钟同时处于“就绪”状态的平均进程数，数值最好小于CPU个数*核心数*0.7。

如果等于，那就是说CPU正好满负载，再多一点，可能就要出问题了，有任务不能被及时分配处理器。

6.1.2CPU利用率（CPUutilization）

CPU的使用时间百分比。

如果该值持续超过95%，表明瓶颈是CPU。

那也许该增加一个处理器或换一个更快的处理器，如果服务器专用于SQLServer，可接受的最大上限是80-85%。

合理使用范围应该在60%-70%，最好不要超过75%。

6.1.3每秒传入的包数（Pagingrate）

每秒钟读入物理内存或写入页面文件的页数，如果该数值偶尔走高，表明当时有线程竞争内存。

如果持续很高，则内存可能是瓶颈，也有可能是内存访问命中率底。

6.2使用NMON工具监控Linux资源

监控前需要根据服务器的操作系统来安装相应版本的NMON（NMONforSolaris,NMONforLinux）。

为了配合性能测试，我们往往需要将一个时间段内系统资源消耗情况记录下来，这时可以使用命令：

./nmon-f-s10-c360。

说明：

./nmon：

反斜杠后面的命令名为安装的一个文件名（不同版本可能不同）

-f：

按标准格式输出文件名称：

<

hostname>

_YYYYMMDD_HHMM.nmon

-s：

每隔n秒抽样一次，这里为10秒

-c：

取出多少个抽样数量，这里为360，即监控=10*360/3600=1小时

该命令启动后，会在nmon所在目录下生成监控文件，并持续写入资源数据，直至360个监控点收集完成——即监控1小时，这些操作均自动完成，无需手工干预，测试人员可以继续完成其他操作。

如果想停止该监控，需要通过“#ps–ef|grepnmon”查询进程号，然后杀掉该进程以停止监控。

注：

对于NMONforSolaris，可以使用命令：

./sadc10360test。

即每隔10秒抽样一次，抽样360次。

test是文件名，同时还会生成一个test.hostname_yymmdd_hhmm.nmon格式的数据。

由于在Solaris，直接输入上面命令，若关闭shell窗口，或输入命令后回车，则直接退出执行命令。

为了使命令能在后台执行，命令要改为：

nohup./sadc10360test&

UNIX操作系统监控命令：

vmstat\iostat\top\sat\sag；

6.2.1系统资源汇总（SYS_SUMM）

系统资源汇总如下图所示，显示了系统CPU及IO资源的总体使用情况。

CPU%值持续超过95%，表明瓶颈是CPU。

如果服务器专用于SQLServer，可接受的最大上限是80-85%。

图6-1系统资源汇总

6.2.2磁盘资源汇总（DISK_SUMM）

可以通过磁盘的详细信息来帮助判断磁盘IO值偏高的原因（若认为磁盘IO值偏高）。

如果磁盘写入数据较多，平均值达到每秒450KB，可以判断这是造成磁盘IO偏高的主要原因，那么结合系统实际设置，可以进一步确定造成问题的原因，如系统日志级别过低等等。

下图是磁盘资源汇总图：

图6-2磁盘资源汇总

6.2.3内存资源（MEM）

内存资源主要有两项指标：

实际剩余内存百分比（RealFree%），实际内存总体大小（Realtotal（MB））。

通过这两个指标，可以知道内存的使用情况。

下图为内存资源图。

图6-3内存资源

7网络监控器图

7.1“网络延迟时间”图（NetworkDelayTime）

在使用“网络延迟时间”图前，需要添加要监控的路径。

例如需要监控数据库服务器和VuserLoadGenerator之间的网络延迟时间，在Controller的“网络延迟时间”图-点击右键，选择“AddMeasurements”-在NetworkDelayTime对话框的“Monitorthenetworkdelayfrommachine:

”区域点击“Add”–输入数据库服务器的IP地址–在“Tomachine（s）:

”区域点击“Add”–输入VuserLoadGenerator（即负载机）的IP地址–点击“OK”，即可监控数据库服务器和VuserLoadGenerator之间的网络延迟时间。

下图将网络延迟显示为场景已用时间的函数。

图中显示，在场景开始后的第8分钟，

有16毫秒的延迟。

图7-1“网络延迟时间”图

也可以通过“网络子路径时间”图、“网络段延迟”图来查看某网络段的延迟时间。

为了验证网络瓶颈，可以合并多个图来确定瓶颈是否由网络引起。

例如，使用“网络延迟时间”和“运行Vuser”图可以确定Vuser的数目如何影响网络延迟。

“网络延迟时间”图显示负载测试场景运行期间的网络延迟。

“运行Vuser”图显示正在运行的Vuser数目。

在下面的合并图中，将网络延迟与正在运行的Vuser数目进行了对比。

此图显示，当10个Vuser全部运行时，出现了22毫秒的网络延迟，暗示网络可能已超载。

图7-2“网络延迟时间-运行Vuser”图

8数据库服务器资源图

8.1Oracle服务器监控度量

使用LoadRunner监控Oracle服务器需要设置Oracle监控环境，具体请参与LR11的用户操作手册《HPLoadRunnerControllerUserGuide》如何设置Oracle监控环境章节，或参考《研发-orcal数据库监控配置》。

监控Oracle服务器时最常使用以下度量（来自V$SYSSTAT表）：

度量

说明

CPUusedbythissession

从用户调用开始到结束之间会话使用的CPU时间（几十毫秒）。

部分用户调用可以在10毫秒内完成，因此用户调用的启动和结束时间可能相同。

在此例中，统计数据增加了0毫秒。

操作系统报告中可能存在类似的问题，尤其是在频繁进行上下文切换的系统上。

Bytesreceivedvia

SQL*Netfromclient

通过Net8从客户端收到的总字节数。

Logonscurrent

当前登录总次数。

Opensofreplacedfiles

因不再位于进程文件高速缓存而需要重新打开的文件总数。

Usercalls

每次登录、解析或执行时，Oracle都分配资源（调用状态对象）以跟踪相关用户调用数据结构。

在确定活动时，用户调用与RPI调用的比率可以表明用户发送到Oracle的各类请求将生成多少内部工作量。

SQL*Netroundtripsto/

fromclient

向客户端发送和从客户端接收的Net8消息总数。

BytessentviaSQL*Netto

client

从前台进程发送到客户端的总字节数。

Openedcursorscurrent

当前打开光标的总数。

DBblockchanges

此统计数据与一致性更改密切相关，计算的是对SGA中所有块进行更改（作为更新或删除操作的一部分）的总次数。

这些更改将生成重做日志条目，如果提交事务，将永久更改数据库。

此统计数据是数据库总负载的粗略表示，指示缓冲区被弄脏的比率（各个事务级别可能有所不同）。

Totalfileopens

实例打开文件的总次数。

每个进程都需要许多文件（控制文件、日志文件、数据库文件）才能使用数据库。

8.1.1添加Oracle自定义计数器

LR自带的计数器，有时候不足以满足监控的需求，故需要手动添加自定义的Oracle计数器。

添加步骤如下：

1）在LR的安装目录“\HP\LoadRunner\dat\monitors”下找到文件“vmon.cfg”

2）打开该文件“vmon.cfg”，找到第三行“CustomCounters=xx”（其中xx为目前已定义的自定义计数器个数），把自定义计数器个数“xx”改为（原个数+本次添加的个数）总和

3）在该文件“vmon.cfg”中以下面格式插入相应的计数器定义说明：

;

[Custom0]

Namemustbeunique

Name=FiveHundred

Description=Thiscounteralwaysreturns500.

Query=SELECT500FROMDUAL

IsRate=0

其中，“[Custom0]”的序号“0”应改为相应的序号（序号必须由“0”开始连续加1递增，如0，1，2…；

若本来已有自定义计数器，由序号由原有序号开始递增。

）

下面为增加的12个计数器：

Name=库快存命中率

Description=命中率应大于0.9

Query=SELECT100*（（sum（pins-reloads））/sum（pins））fromv$librarycache

[Custom1]

Name=高速缓存区命中率

Query=SELECTround（1-SUM（PHYSICAL_READS）/（SUM（DB_BLOCK_GETS）+SUM（CONSISTENT_GETS））,4）*100FROM（SELECTCASEWHENNAME='

physicalreads'

THENVALUEENDPHYSICAL_READS,CASEWHENNAME='

dbblockgets'

THENVALUEENDDB_BLOCK_GETS,CASEWHENNAME='

consistentgets'

THENVALUEENDCONSISTENT_GETSFROMV$SYSSTATWHERENameIN（'

'

））

[Custom2]

Name=共享区库缓存区命中率

Description=命中率应大于0.99

Query=Selectround（sum（pins-reloads）/sum（pins）*100,2）fromv$librarycache

[Custom3]

Name=共享区字典缓存区命中率

Description=命中率应大于0.85

Query=Selectround（sum（gets-getmisses-usage-fixed）/sum（gets）*100,2）fromv$rowcache

[Custom4]

Name=检测回滚段的争用

Description=应该小于1%

Query=selectround（sum（waits）/sum（gets）*100,2）fromv$rollstat

[Custom5]

Name=检测回滚段收缩次数

Description=应该

Query=selectsum（shrinks）fromv$rollstat,v$rollnamewherev$rollstat.usn=v$rollname.usn

[Custom6]

Name=监控表空间的I/O读总数

Description=监控表空间的I/O

Query=selectsum（f.phyrds）pyrfromv$filestatf,dba_data_filesdfwheref.file#=df.file_id

[Custom7]

Name=监控表空间的I/O块读总数