性能测试指标文档格式.docx

上传人:b****6 文档编号:17038847 上传时间:2022-11-28 格式:DOCX 页数:10 大小:94.42KB
下载 相关 举报
性能测试指标文档格式.docx_第1页
第1页 / 共10页
性能测试指标文档格式.docx_第2页
第2页 / 共10页
性能测试指标文档格式.docx_第3页
第3页 / 共10页
性能测试指标文档格式.docx_第4页
第4页 / 共10页
性能测试指标文档格式.docx_第5页
第5页 / 共10页
点击查看更多>>
下载资源
资源描述

性能测试指标文档格式.docx

《性能测试指标文档格式.docx》由会员分享,可在线阅读,更多相关《性能测试指标文档格式.docx(10页珍藏版)》请在冰豆网上搜索。

性能测试指标文档格式.docx

此图可以查看

虚拟用户负载对执行时间的总体影响,对分析具有渐变负载的测试场景比较有用。

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

“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图,也就

是工具通过一些统计分析方法间接得到的图表。

通过它可以分析在给定事务响应

时间范围内能执行的事务百分比。

TransactionResponseTime(Distribution)(事务响应时间(分布))

“事务响应时间(分布)”显示在场景运行过程中,事务执行所用时间的分布,通

过它可以了解测试过程中不同响应时间的事务数量。

如果系统预先定义了相关事

务可以接受的最小和最大事务响应时间,则可以使用此图确定服务器性能是否在

可以接受的范围内。

WebResources(Web资源分析)

Web资源分析是从服务器入手对Web服务器的性能分析。

HitsperSecond(每秒点击次数)

“每秒点击次数”,即使运行场景过程中虚拟用户每秒向Web服务器提交的HTT

P请求数。

通过它可以评估虚拟用户产生的负载量,如将其和“平均事务响应时间”图比较,

可以查看点击次数对事务性能产生的影响。

通过对查看“每秒点击次数”,可以

判断系统是否稳定。

系统点击率下降通常表明服务器的响应速度在变慢,需进一

步分析,发现系统瓶颈所在。

Throughput(吞吐率)

“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。

其度量单位是字节,

表示虚拟用在任何给定的每一秒从服务器获得的数据量。

可以依据服务器的吞吐量来评估虚拟用户产生的负载量,以及看出服务器在流量

方面的处理能力以及是否存在瓶颈。

“吞吐率”图和“点击率”图的区别:

“吞吐率”图,是每秒服务器处理的HTTP申请数。

“点击率”图,是客户端每秒从服务器获得的总数据量。

HTTPStatusCodeSummary(HTTP状态代码概要)

“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状

态代码数,该图按照代码分组。

HTTP状态代码表示HTTP请求的状态。

HTTPResponsesperSecond(每秒HTTP响应数)

“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP

状态代码的数量,还能返回其它各类状态码的信息,通过分析状态码,可以判断

服务器在压力下的运行情况,也可以通过对图中显示的结果进行分组,进而定位

生成错误的代码脚本。

PagesDownloaderperSecond(每秒下载页面数)

“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。

使用此图可依据下载的页数来计算Vuser生成的负载量。

和吞吐量图一样,每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收

到的数据量。

但是吞吐量考虑的各个资源极其大小(例,每个GIF文件的大小、

每个网页的大小)。

而每秒下载页面数只考虑页面数。

注:

要查看每秒下载页数图,必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。

RetriesperSecond(每秒重试次数)

“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。

在下列情况将重试服务器连接:

A、初始连接XX

B、要求代理服务器身份验证

C、服务器关闭了初始连接

D、初始连接无法连接到服务器

E、服务器最初无法解析负载生成器的IP地址

RetriesSummary(重试次数概要)

“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数,它按

照重试原因分组。

将此图与每秒重试次数图一起使用可以确定场景或会话步骤运

行过程中服务器在哪个时间点进行了重试。

Connections(连接数)

“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。

借助此图,可以知道何时需要添加其他连接。

例:

当连接数到达稳定状态而事务响应时间迅速增大时,添加连接可以使性能得

到极大提高(事务响应时间将降低)。

ConnectionsPerSecond(每秒连接数)

“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。

理想情况下,很多HTTP请求都应该使用同一连接,而不是每个请求都新打开一

个连接。

通过每秒连接数图可以看出服务器的处理情况,就表明服务器的性能在

逐渐下降。

SSLsPerSecond(每秒SSL连接数)

“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使

用的SSL连接数。

当对安全服务器打开TCP/IP连接后,浏览器将打开SSL连接。

WebPageBreakdown(网页元素细分)

“网页元素细分”主要用来评估页面内容是否影响事务的响应时间,通过它可以

深入地分析网站上那些下载很慢的图形或中断的连接等有问题的

元素。

WebPageBreakdown(页面分解总图)

“页面分解”显示某一具体事务在测试过程的响应情况,进而分析相关的事务运

行是否正常。

“页面分解”图可以按下面四种方式进行进一步细分:

DownloadTimeBreaddown(下载时间细分)

“下载时间细分”图显示网页中不同元素的下载时间,同时还可按照下载过程把

时间进行分解,用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲

时间等各自所占比例。

ComponentBreakdown(OverTime)(组件细分(随时间变化))

“组件细分”图显示选定网页的页面组件随时间变化的细分图。

通过该图可以很

容易的看出哪些元素在测试过程中下载时间不稳定。

该图特别适用于需要在客户

端下载控件较多的页面,通过分析控件的响应时间,很容易就能发现那些控件不

稳定或者比较耗时。

DownloadTimeBreakdown(OverTime)(下载时间细分(随时间变化))

“下载时间细分(随时间变化)”图显示选定网页的页面元素下载时间细分(随

时间变化)情况,它非常清晰地显示了页面各个元素在压力测试过程中的下载情

况。

“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果,

“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应

时间的统计结果,两者分别从宏观和微观角度来分析页面元素的下载时间。

TimetoFirstBufferBreakdown(OverTime)(第一次缓冲时间细分(随时间变化))

“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一

次缓冲之前的这段时间,场景或会话步骤运行的每一秒中每个网页组件的服务器

时间和网络时间(以秒为单位)。

可以使用该图确定场景或会话步骤运行期间服

务器或网络出现问题的时间。

PageComponentBreakdown(页面组件细分)

“页面组件细分”图显示每个网页及其组件的平均下载时间(以秒为单位)。

以根据下载组件所用的平均秒数对图列进行排序,通过它有助于隔离有问题的组

件。

PageComponentBreakdown(OverTime)(页面组件分解(随时间变化))

“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其

组件的平均响应时间(以秒为单位)。

PageDownloadTimeBreakdown(页面下载时间细分)

“页面下载时间细分”图显示每个页面组件下载时间的细分,可以根据它确定在

网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。

“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL

握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下

载过程进行细分。

PageDownloadTimeBreakdown(OverTime)(页面下载时间细分(随时

间变化))

“页面下载时间细分(随时间变化)”图显示方案运行期间,每一秒内每个页面组

件下载时间的细分。

使用此图可以确定网络或服务器在方案执行期间哪一时间点

发生了问题。

“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常

结合起来进行分析:

首先确定有问题的组件,然后分析它们的下载过程,进而定

位原因在哪里。

TimetoFirstBufferBreakdown(第一次缓冲时间细分)

“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的

这一段时间内的每个页面组件的相关服务器/网路时间。

如果组件的下载时间很

长,则可以使用此图确定产生的问题与服务器有关还是与网络有关。

网络时间:

定义为第一个HTTP请求那一刻开始,直到确认为止所经过的平均时

间。

服务器时间:

定义为从收到初始HTTP请求确认开始,直到成功收到来自Web服

务器的一次缓冲为止所经过的平均时间。

TimetoFirstBufferBreakdown(OverTime)

“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一

个缓冲之前的这段时

2、判断应用程序问题

如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(contextswitches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.

 

  从图的整体看.contextswitches/sec变化不大,throughout曲线的斜率较高,并且此时的contextswitches/sec已经超过了15000.程序还是需要进一步优化.

3、判断CPU瓶颈

如果processorqueuelength显示的队列长度保持不变(>

=2)个并且处理器的利用率%Processortime超过90%,那么很可能存在处理器瓶颈.如果发现processorqueuelength显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈

.

  %processortime平均值大于95,processorqueuelength大于2.可以确定CPU瓶颈.此时的CPU已经不能满足程序需要.急需扩展.

4、判断内存泄露问题

  内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏,process\privatebytes计数器和process\workingset计数器的值往往会升高,同时avaiablebytes的值会降低.内存泄漏应该通过一个长时间的,用来研究分析所有内存都耗尽时,应用程序反应情况的测试来检验.

  

图中可以看到该程序并不存在内存泄露的问题.内存泄露问题经常出现在服务长时间运转的时候,由于部分程序对内存没有释放,而将内存慢慢耗尽.也是提醒大家对系统稳定性测试的关注.

 

5、linux下查看系统指标

Vmstat命令详解

[root@flow54~]#vmstat

procs-----------memory-------------swap-------io------system-------cpu------

rbswpdfreebuffcachesisobiboincsussyidwast

10120561838921459569012280011300109900

r:

等待运行的进程数b:

处在非中断睡眠状态的进程数

Memory

swpd:

虚拟内存使用情况,单位:

KB

free:

空闲的内存,单位KB

buff:

被用来做为缓存的内存数,单位:

Swap

si:

从磁盘交换到内存的交换页数量,单位:

KB/秒

so:

从内存交换到磁盘的交换页数量,单位:

bi:

发送到块设备的块数,单位:

块/秒

bo:

从块设备接收到的块数,单位:

System

in:

每秒的中断数,包括时钟中断

cs:

每秒的环境(上下文)切换次数

CPU

按CPU的总使用百分比来显示

us:

CPU使用时间

sy:

CPU系统使用时间

id:

闲置时间

准测:

r<

5,b≈0,

如果fre<

MINFREE,将会出现连续不断的页面调度,将导致系统性能问题

对于page列,re,pi,po,cy维持于比较稳定的状态,PI率不超过5,如果有pagin发生,那么关联页面必须先进行pageout

在内存相对紧张的环境下pagein会强制对不同的页面进行steal操作。

如果系统正在读一个大批的永久页面,你也许可以看到po和pi列

会出现不一致的增长,这种情景并不一定表明系统负载过重,但是有必要对应用程序的数据访问模式进行见检查。

在稳定的情况下,扫描率和重置率几乎相等,在

多个进程处理使用不同的页面的情况下,页面会更加不稳定和杂乱,这时扫描率可能会比重置率高出

6、监视linux资源

前提条件需要在linux机器上启动rstatd守护进程;

如果linux系统没有安装过,需要重新下载去安装一下。

下载rpc.rstatd-4.0.1.tar.gz

tar-xzvfrpc.rstatd-4.0.1.tar.gz

cdrpc.rstatd-4.0.1/

./configure—配置操作

make—进行编译

makeinstall—开始安装

rpc.rstatd—启动

rstatd进程

rpcinfo–p命令来查看当前系统是否已经启动了

检查是否启动成功的命令:

rpcinfo-p,如果返回结果类似信息如下,则表明启动成功:

1000015udp937rstatd

1000014udp937rstatd

确定步骤1已经安装过并正常启动了。

在loadrunner的Controller中,将UNIXresources拖放到右侧,右键该窗体选AddMeasurements,添加被监控的linuxIP地址,选择监控的具体指标

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 文学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1