1、用户事务分析 算法
用户事务分析是站在用户角度进行的基础性能分析。 sql
1、Transation Sunmmary(事务综述) 数据库
对事务进行综合分析是性能分析的第一步,经过分析测试时间内用户事务的成功与失败状况,能够直接判断出系统是否运行正常。 浏览器
2、Average Transaciton Response Time(事务平均响应时间) 缓存
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间,经过它能够分析测试场景运行期间应用系统的性能走向。根据该图,能够定位出现性能问题的转折点。 安全
说明:随着测试时间的变化,系统处理事务的速度开始逐渐变慢,这说明应用系统随着投产时间的变化,总体性能将会有降低的趋势。 服务器
当事务响应时间的曲线开始由缓慢上升,而后处于平衡,最后慢慢降低,可能状况: 网络
1)曲线图持续上升,代表系统的处理能力在降低,事务的响应时间变长; 并发
2)持续平衡,代表并发用户数达到必定数量,再多请求也可能接受不了,等待; 数据库设计
3)当事务的响应时间在降低,代表并发用户的数量在慢慢减小,事务的请求数也在减小。
若是系统没有出现降低,但响应时间愈来愈长,直到系统瘫痪,引发缘由可能以下:
1)程序中用户数链接未作限制,致使请求数不断上升,响应时间不断变长;
2)内存泄露。
3、Transactions per Second(每秒经过事务数,简写TPS)
“每秒经过事务数/TPS”显示在场景运行的每一秒钟,每一个事务经过、失败以及中止的数量,使考查系统性能的一个重要参数。经过它能够肯定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。将它与平均事务响应时间进行对比,能够分析事务数目对执行时间的影响。
说明:当压力加大时,点击率/TPS曲线若是变化缓慢或者有平坦的趋势,颇有多是服务器开始出现瓶颈。TPS值,越大说明系统处理能力越强。
4、Total Transactions per Second(每秒经过事务总数)
“每秒经过事务总数”显示在场景运行时,在每一秒内经过的事务总数、失败的事务总署以及中止的事务总数。该曲线走向和TPS曲线走向一致。
5、Transaction Performance Sunmmary(事务性能摘要)
“事务性能摘要”显示方案中全部事务的最小、最大和平均执行时间,能够直接判断响应时间是否符合用户的要求。
说明:重点关注事务的平均和最大执行时间,若是其范围不在用户能够接受的时间范围内,须要进行缘由分析。
6、Transaction Response Time Under Load(事务响应时间与负载)
“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合,经过它能够看出在任一时间点事务响应时间与用户数目的关系,从而掌握系统在用户并发方面的性能数据,为扩展用户系统提供参考。此图能够查看虚拟用户负载对执行时间的整体影响,对分析具备渐变负载的测试场景比较有用。
7、Transaction Response Time(Percentile)(事务响应时间(百分比))
“事务响应时间(百分比)”是根据测试结果进行分析而获得的综合分析图,也就是工具经过一些统计分析方法间接获得的图表。经过它能够分析在给定事务响应时间范围内能执行的事务百分比。
说明:主要观察,在给定时间的范围内完成事务的百分比
参考值: 10%的TRT(P)<=5s、50%的TRT(P)<=5s、90%的TRT(P)<=5s
八、Transaction Response Time(Distribution)(事务响应时间(分布))
“事务响应时间(分布)”显示在场景运行过程当中,事务执行所用时间的分布,经过它能够了解测试过程当中不一样响应时间的事务数量。若是系统预先定义了相关事务能够接受的最小和最
大事务响应时间,则可使用此图肯定服务器性能是否在能够接受的范围内。
说明:主要观察,大多数事务的响应时间
参考值:TRT(D)<=5s
2、肯定CPU、内存泄露问题
1、%processor time(processor_total)
服务器消耗的处理器时间数量.若是服务器专用于sql server 可接受的最大上限是80% -85 %.也就是常见的CPU 使用率。
说明:正常负载下,服务器的CPU利用率应该在80%如下。超过90%,那么极可能存在处理器瓶颈。若是CPU使用率不断上升,内存使用率也不断上升,代表系统可能产生资源争用状况,引发缘由,程序资源调配问题。
判断是否内存泄露问题:
内存问题主要检查应用程序是否存在内存泄漏,若是发生了内存泄漏,P rocess Bytes\Private Bytes计数器和Process\Working set 计数器的值每每会升高,同时Avaiable bytes的值会下降。内存泄漏应该经过一个长时间的,用来研究分析全部内存都耗尽时,应用程序反应状况的测试来检验。内存泄露问题常常出如今服务长时间运转的时候,因为部分程序对内存没有释放,而将内存慢慢耗尽,也是提醒你们对系统稳定性测试的关注。
2、%Disk time(physicaldisk_total)
指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。若是三个计数器都比较大,那么硬盘不是瓶颈。若是只有%Disk Time比较大,另外两个都比较适中,硬盘可能会是瓶颈。在记录该计数器以前,请在Windows 2000 的命令行窗口中运行diskperf -yD。
说明:正常值<10。若数值持续超过80%,则多是内存泄漏。
3、Availiable bytes(memory)
用物理内存数. 若是Available Mbytes的值很小(4 MB 或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。
参考值:4 MB或更小,至少要有10%的物理内存值。
4、Page write/sec
(写的页/秒)每秒执行的物理数据库写的页数。
说明:若是服务器没有足够的内存处理其工做负荷,此数值将一直很高。若是大于80,表示有问题(太多的读写数据操做要访问磁盘,可考虑增长内存或优化读写数据的算法)。
【其余参数】
%User time(processor_total)
表示耗费CPU的数据库操做,如排序,执行aggregate functions等。若是该值很高,可考虑增长索引,尽可能使用简单的表联接,水平分割大表格等方法来下降该值。
%DPC time(processor_total)
越低越好。在多处理器系统中,若是这个值大于50%而且Processor:% Processor Time很是高,加入一个网卡可能会提升性能,提供的网络已经不饱和。
Context switch/sec(system)
(实例化inetinfo 和dllhost 进程) 若是你决定要增长线程字节池的大小,你应该监视这三个计数器(包括上面的一个)。增长线程数可能会增长上下文切换次数,这样性能不会上升反而会降低。若是十个实例的上下文切换值很是高,就应该减少线程字节池的大小。
说明:可判断应用程序的问题。若是系统因为应用程序代码效率低下或者系统结构设计有缺陷而致使大量的上下文切换(Context switches/sec显示的上下文切换次数过高)那么就会占用大量的系统资源,若是系统的吞吐量下降而且CPU的使用率很高,而且此现象发生时切换水平在15000以上,那么意味着上下文切换次数太高。
%Disk reads/sec(physicaldisk_total)
每秒读硬盘字节数.
%Disk write/sec(physicaldisk_total)
每秒写硬盘字节数.
Page faults/sec
进程产生的页故障与系统产生的相比较,以判断这个进程对系统页故障产生的影响。
Pages per second
每秒钟检索的页数
该数字应少于每秒一页Working set:理线程最近使用的内存页,反映了每个进程使用的内存页的数量。若是服务器有足够的空闲内存,页就会被留在工做集中,当自由内存少于一个特定的阈值时,页就会被清除出工做集。
Avg.disk queue length
读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提升性能,可增长磁盘。注意:一个Raid Disk实际有多个磁盘。
Average disk read/write queue length
指读取(写入)请求(列队)的平均数Disk reads/(writes)/s:理磁盘上每秒钟磁盘读、写的次数。二者相加,应小于磁盘设备最大容量。
Average disk sec/read
以秒计算的在此盘上读取数据的所需平均时间。Average disk sec/transfer:指以秒计算的在此盘上写入数据的所需平均时间。
Bytes total/sec
为发送和接收字节的速率,包括帧字符在内。判断网络链接速度是不是瓶颈,能够用该计数器的值和目前网络的带宽比较Page read/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在全部数据库间的物理页读取总数。因为物理 I/O 的开销大,能够经过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,使开销减到最小。
3、肯定网络问题:
1、Hits per Second(每秒点击次数)
“每秒点击次数”,即便运行场景过程当中虚拟用户每秒向Web服务器提交的HTTP请求数。 经过它能够评估虚拟用户产生的负载量,如将其和“平均事务响应时间”图比较,能够查看点击次数对事务性能产生的影响。
说明:经过对查看“每秒点击次数”,能够判断系统是否稳定。系统点击率降低一般代表服务器的响应速度在变慢,需进一步分析,发现系统瓶颈所在。
2、Throughput(吞吐率)
“吞吐率”显示的是场景运行过程当中服务器的每秒的吞吐量。其度量单位是字节,表示虚拟用在任何给定的每一秒从服务器得到的数据量。能够依据服务器的吞吐量来评估虚拟用户产生的负载量,以及看出服务器在流量方面的处理能力以及是否存在瓶颈。 “吞吐率”图,是每秒服务器处理的HTTP申请数。 “点击率”图,是客户端每秒从服务器得到的总数据量。
说明:观察3张图(Running Vusers(负载数)/His per Second(点击率)/Throughput(吞吐量)),随着负载的加大,点击率和吞吐量会随之增大。若是系统的吞吐量随着负载的加大出现平坦或下降而且CPU的使用率很高,而且此现象发生时切换水平在15000以上,那么意味着上下文切换次数太高,代表网络饱和。
3、Network Delay Time
说明:网络延迟时间的曲线突起显示有网络故障。
4、Network Sub-Path Time
说明:网络Sub-Path的时间曲线跳跃式的突起证实存在网络故障。
4、肯定性能问题是在网络端仍是服务端:
1、Web Page Breakdown(页面分解总图)
“页面分解”显示某一具体事务在测试过程的响应状况,进而分析相关的事务运行是否正常。能够按下面四种方式进行进一步细分:
Download Time Breaddown(下载时间细分)
“下载时间细分”图显示网页中不一样元素的下载时间,同时还可按照下载过程把时间进行分解,用不一样的颜色来显示DNS解析时间、创建链接时间、第一次缓冲时间等各自所占比例。
Component Breakdown(Over Time)(组件细分(随时间变化))
“组件细分”图显示选定网页的页面组件随时间变化的细分图。经过该图能够很容易的看出哪些元素在测试过程当中下载时间不稳定。该图特别适用于须要在客户端下载控件较多的页面,经过分析控件的响应时间,很容易就能发现那些控件不稳定或者比较耗时。
Download Time Breakdown(Over Time)(下载时间细分(随时间变化))
“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分(随时间变化)状况,它很是清晰地显示了页面各个元素在压力测试过程当中的下载状况。
“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果,“下载时间细分(随时间变化)”显示的事场景运行过程当中每一秒内页面元素响应时间的统计结果,二者分别从宏观和微观角度来分析页面元素的下载时间。
Time to First Buffer Breakdown(Over Time)(第一次缓冲时间细分(随时间变化))
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲以前的这段时间,场景或会话步骤运行的每一秒中每一个网页组件的服务器时间和网络时间(以秒为单位)。可使用该图肯定场景或会话步骤运行期间服务器或网络出现问题的时间。
First Buffer Time:是指客户端与服务器端创建链接后,从服务器发送第一个数据包开始计时,数据通过网络传送到客户端,到浏览器接收到第一个缓冲所用的时间。
2、Page Component Breakdown(页面组件细分)
“页面组件细分”图显示每一个网页及其组件的平均下载时间(以秒为单位)。能够根据下载组件所用的平均秒数对图列进行排序,经过它有助于隔离有问题的组件。
3、Page Component Breakdown(Over Time)(页面组件分解(随时间变化))
“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每一个网页及其组件的平均响应时间 (以秒为单位)。
4、Page Download Time Breakdown(页面下载时间细分)
“页面下载时间细分”图显示每一个页面组件下载时间的细分,能够根据它肯定在网页下载期间事务响应时间缓慢是由网络错误引发仍是由服务器错误引发。
“页面下载时间细分”图根据DNS解析时间、链接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每一个组件的下载过程进行细分。
5、Page Download Time Breakdown(Over Time)(页面下载时间细分(随时间变化))
“页面下载时间细分(随时间变化)”图显示方案运行期间,每一秒内每一个页面组件下载时间的细分。使用此图能够肯定网络或服务器在方案执行期间哪一时间点发生了问题。 “页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图一般结合起来进行分析:首先肯定有问题的组件,而后分析它们的下载过程,进而定位缘由在哪里。
6、Time to First Buffer Breakdown(第一次缓冲时间细分)
“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲以前的这一段时间内的每一个页面组件的相关服务器/网路时间。若是组件的下载时间很长,则可使用此图肯定产生的问题与服务器有关仍是与网络有关。
网络时间:定义为第一个HTTP请求那一刻开始,直到确认为止所通过的平均时间。 服务器时间:定义为从收到初始HTTP请求确认开始,直到成功收到来自Web服务器的一次缓冲为止所通过的平均时间。
说明:找出下载耗费时间最多的网页。有助排出DNS的故障,SSL的故障,网络链接的故障。
【其余Web资源分析】
1、HTTP Status Code Summary(HTTP状态代码概要)
“HTTP状态代码概要”显示场景或会话步骤过程当中从Web服务器返回的HTTP状态代码数,该图按照代码分组。HTTP状态代码表示HTTP请求的状态。
2、HTTP Responses per Second(每秒HTTP响应数)
“每秒HTTP响应数”是显示运行场景过程当中每秒从Web服务器返回的不一样HTTP状态代码的数量,还能返回其它各种状态码的信息,经过分析状态码,能够判断服务器在压力下的运行状况,也能够经过对图中显示的结果进行分组,进而定位生成错误的代码脚本。
3、Pages Downloader per Second(每秒下载页面数)
“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
和吞吐量图同样,每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。可是吞吐量考虑的各个资源极其大小(例,每一个GIF文件的大小、每一个网页的大小)。而每秒下载页面数只考虑页面数。
注:要查看每秒下载页数图,必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。
四、Retries per Second(每秒重试次数)
“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的链接次数。 在下列状况将重试服务器链接: A、初始链接未经受权 B、要求代理服务器身份验证 C、服务器关闭了初始链接 D、初始链接没法链接到服务器
E、服务器最初没法解析负载生成器的IP地址
5、Retries Summary(重试次数概要)
“重试次数概要”显示场景或会话步骤运行过程当中服务器尝试的链接次数,它按照重试缘由分组。将此图与每秒重试次数图一块儿使用能够肯定场景或会话步骤运行过程当中服务器在哪一个时间点进行了重试。
6、Connections(链接数)
“链接数”显示场景或会话步骤运行过程当中每一个时间点打开的TCP/IP链接数。 借助此图,能够知道什么时候须要添加其余链接。
说明:当链接数到达稳定状态而事务响应时间迅速增大时,添加链接可使性能获得极大提升(事务响应时间将下降)。
七、Connections Per Second(每秒链接数)
“每秒链接数”显示方案在运行过程当中每秒创建的TCP/IP链接数。
理想状况下,不少HTTP请求都应该使用同一链接,而不是每一个请求都新打开一个链接。经过每秒链接数图能够看出服务器的处理状况,就代表服务器的性能在逐渐降低。
8、SSLs Per Second(每秒SSL链接数)
“每秒SSL链接数”显示场景或会话步骤运行的每一秒内打开的新的以及从新使用的SSL链接数。当对安全服务器打开TCP/IP链接后,浏览器将打开SSL链接。
9、Web Page Breakdown(网页元素细分)
“网页元素细分”主要用来评估页面内容是否影响事务的响应时间,经过它能够深刻地分析网站上那些下载很慢的图形或中断的链接等有问题的 元素。
10、Time to First Buffer Breakdown(Over Time)(第一次缓冲时间细分(随时间变化))
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲以前的这段时间内,场景运行的每一秒中每一个网页组件的服务器时间和网络时间。可使用此图肯定场景运行期间服务器或网络出现问题的时间点。
11、Downloader Component Size(KB)(已下载组件大小)
“已下载组件大小”图显示每一个已经下载的网页组建的大小。经过它能够直接看出哪些组件比较大并须要进一步进行优化以提升性能。