1、性能测试指标1、 LR指标概念Transation Sunmmary（事务综述）对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。Average Transaciton Response Time（事务平均响应时间）“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。Transactions per Second（每秒通过事务数/TPS）“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过
2、它可以确定系统在任何给定时刻的时间事务负载。分析TPS 主要是看曲线的性能走向。Total Transactions per Second（每秒通过事务总数）“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。Transaction Performance Sunmmary（事务性能摘要）“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。Transaction Response Time Under Loa
3、d（事务响应时间与负载）“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。Transaction Response Time(Percentile)（事务响应时间(百分比)）“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。Transaction
4、 Response Time(Distribution)（事务响应时间(分布)）“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。Web Resources（Web 资源分析）Web 资源分析是从服务器入手对Web 服务器的性能分析。Hits per Second（每秒点击次数）“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web 服务器提交的HTTP 请求数。通过它可以评估虚拟用户产生的负载量，如将其和“平均事
5、务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。Throughput（吞吐率）“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。“吞吐率”图和“点击率”图的区别：“吞吐率”图，是每秒服务器处理的HTTP 申请数。“点击率”图，是客户端每秒从服务器获得的总数据量。HTTP Status C
6、ode Summary（HTTP 状态代码概要）“HTTP 状态代码概要”显示场景或会话步骤过程中从Web 服务器返回的HTTP 状态代码数，该图按照代码分组。HTTP 状态代码表示HTTP 请求的状态。HTTP Responses per Second（每秒HTTP 响应数）“每秒HTTP 响应数”是显示运行场景过程中每秒从Web 服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。Pages Downloader per Second（每秒下载页面数）“每秒下
7、载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser 生成的负载量。和吞吐量图一样，每秒下载页面数图标是Vuser 在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF 文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。注：要查看每秒下载页数图，必须在R-T-S 那里设置“每秒页面数(仅HTML 模式)”。Retries per Second（每秒重试次数）“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。在下列情况将重试服务器连接：A、初始连接XXB、要求代理服务器身份验证C
8、、服务器关闭了初始连接D、初始连接无法连接到服务器E、服务器最初无法解析负载生成器的IP 地址Retries Summary（重试次数概要）“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。Connections（连接数）“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP 连接数。借助此图，可以知道何时需要添加其他连接。例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。Connections Per
9、 Second（每秒连接数）“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP 连接数。理想情况下，很多HTTP 请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。SSLs Per Second（每秒SSL 连接数）“每秒SSL 连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL 连接数。当对安全服务器打开TCP/IP 连接后，浏览器将打开SSL 连接。Web Page Breakdown（网页元素细分）“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那
10、些下载很慢的图形或中断的连接等有问题的元素。Web Page Breakdown（页面分解总图）“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。“页面分解”图可以按下面四种方式进行进一步细分：Download Time Breaddown（下载时间细分）“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS 解析时间、建立连接时间、第一次缓冲时间等各自所占比例。Component Breakdown(Over Time)（组件细分(随时间变化)）“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该
11、图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页
12、面元素的下载时间。Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web 服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。Page Component Breakdown（页面组件细分）“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。Page Co
13、mponent Breakdown(Over Time)（页面组件分解(随时间变化)）“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。Page Download Time Breakdown（页面下载时间细分）“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。“页面下载时间细分”图根据DNS 解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP 验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。Page Download
14、Time Breakdown(Over Time)（页面下载时间细分(随时间变化)）“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。Time to First Buffer Breakdown（第一次缓冲时间细分）“第一次缓冲时间细分”图显示成功收到从Web 服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间
15、。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。网络时间：定义为第一个HTTP 请求那一刻开始，直到确认为止所经过的平均时间。服务器时间：定义为从收到初始HTTP 请求确认开始，直到成功收到来自Web 服务器的一次缓冲为止所经过的平均时间。Time to First Buffer Breakdown(Over Time) “第一次缓冲时间细分(随时间变化)”图显示成功收到从Web 服务器返回的第一个缓冲之前的这段时2、判断应用程序问题如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(context switches/sec显示的上下
16、文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.从图的整体看.context switches/sec变化不大,throughout曲线的斜率较高,并且此时的contextswitches/sec已经超过了15000.程序还是需要进一步优化.3、判断CPU瓶颈如果processor queue length显示的队列长度保持不变(=2)个并且处理器的利用率%Processortime超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长
17、度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.%processor time平均值大于95,processor queue length大于2.可以确定CPU瓶颈.此时的CPU已经不能满足程序需要.急需扩展.4、判断内存泄露问题内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏,processprivate bytes计数器和processworking set 计数器的值往往会升高,同时avaiable bytes的值会降低.内存泄漏应该通过一个长时间的,用来研究分析所有内存都耗尽时,应用程序反应情况的测试来检验.图中可以看到该程序并
18、不存在内存泄露的问题.内存泄露问题经常出现在服务长时间运转的时候,由于部分程序对内存没有释放,而将内存慢慢耗尽.也是提醒大家对系统稳定性测试的关注.5、linux下查看系统指标Vmstat命令详解rootflow54 # vmstatprocs -memory- -swap- -io- -system- -cpu- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 12056 183892 145956 901228 0 0 1 13 0 0 1 0 99 0 0r: 等待运行的进程数 b: 处在非中断睡眠状态的进程数M
19、emory swpd: 虚拟内存使用情况，单位：KBfree: 空闲的内存，单位KBbuff: 被用来做为缓存的内存数，单位：KBSwap si: 从磁盘交换到内存的交换页数量，单位：KB/秒so: 从内存交换到磁盘的交换页数量，单位：KB/秒bi: 发送到块设备的块数，单位：块/秒bo: 从块设备接收到的块数，单位：块/秒System in: 每秒的中断数，包括时钟中断cs: 每秒的环境（上下文）切换次数CPU 按 CPU 的总使用百分比来显示 us: CPU 使用时间sy: CPU 系统使用时间id: 闲置时间准测：r5，b0，如果freMINFREE，将会出现连续不断的页面调度，将导致系
20、统性能问题对于page列，re，pi，po，cy维持于比较稳定的状态，PI率不超过5，如果有pagin发生，那么关联页面必须先进行pageout在内存相对紧张的环境下pagein会强制对不同的页面进行steal操作。如果系统正在读一个大批的永久页面，你也许可以看到po和pi列会出现不一致的增长，这种情景并不一定表明系统负载过重，但是有必要对应用程序的数据访问模式进行见检查。在稳定的情况下，扫描率和重置率几乎相等，在多个进程处理使用不同的页面的情况下，页面会更加不稳定和杂乱，这时扫描率可能会比重置率高出6、监视linux资源前提条件需要在linux机器上启动rstatd守护进程；如果linux系
21、统没有安装过，需要重新下载去安装一下。下载rpc.rstatd-4.0.1.tar.gztar -xzvf rpc.rstatd-4.0.1.tar.gz cd rpc.rstatd-4.0.1/ ./configure 配置操作make 进行编译make install 开始安装rpc.rstatd 启动rstatd进程rpcinfo p 命令来查看当前系统是否已经启动了检查是否启动成功的命令：rpcinfo -p,如果返回结果类似信息如下，则表明启动成功：100001 5 udp 937 rstatd100001 4 udp 937 rstatd确定步骤1已经安装过并正常启动了。在loadrunner的Controller中，将UNIX resources拖放到右侧，右键该窗体选Add Measurements，添加被监控的linuxIP地址，选择监控的具体指标
