一、常用到的性能测试术语
1.事务（Transaction）
在web性能测试中，一个事务表示一个“从用户发送请求->web server接受到请求，进行处理-> web server向DB获取数据->生成用户的object(页面)，返回给用户”的过程，一般的响应时间都是针对事务而言的。
2.请求响应时间
请求响应时间指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，在某些工具中，响应通常会称为“TTLB”，即"time to last byte"，意思是从发起一个请求开始，到客户端接收到最后一个字节的响应所耗费的时间，响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示：响应时间＝网络响应时间+应用程序响应时间。标准可参考国外的3/5/10原则：
（1）在3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”；
（2）在3~5秒钟内，页面给予用户响应并有所显示，可认为是“好的”；
（3）在5~10秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”；
（4）超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去；
3、事务响应时间
事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数.
4.并发用户数
并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。
另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。
可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。
用户并发数量：关于用户并发的数量，有2种常见的错误观点。 一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和其他用户发生并发，例如正在浏览网页的用户，对服务器没有任何影响，但是，在线用户数量是计算并发用户数量的主要依据之一。
5.吞吐量
指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.
6、TPS（transactionper second）
每秒钟系统能够处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.
7、点击率
每秒钟用户向WEB服务器提交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求.
8.资源利用率
指的是对不同的系统资源的使用程度,例如服务器的CPU利用率,磁盘利用率等.资源利用率是分析系统性能指标进而改善性能的主要依据,因此是WEB性能测试工作的重点.
资源利用率主要针对WEB服务器,操作系统,数据库服务器,网络等,是测试和分析瓶颈的主要参考.在WEB性能测试中,更根据需要采集相应的参数进行分析。
点击Graph-->Add New Graph...或是按快捷键打开新视图，也可以
Analysis分析器中提供了丰富的分析图，常见的有如下几类：Vusers图、事务图、Web资源图、网页细分图、错误图、系统资源图、Web服务器资源图、数据库服务器资源图。
将display only graphs containing data复选框的勾去掉，会显示更多的分析图。
（1）Vusers图
在方案执行过程中，Vuser在执行事务时生成数据。使用Vusers图可以确定方案执行期间Vuser的整体行为。它显示Vuser状态和完成脚本的Vuser的数量。主要包括正在运行的Vuser图和Vuser摘要图两种。
（2）Errors图
在方案执行期间，并不是每个Vuser都一定会执行成功，可能有执行失败、停止或因错误而终止的情况。Errors图主要是统计方案执行时的错误信息，主要包括：Error Statistics（By Description）、Error per Second（by Description）的、Error Statistics和Error per Second四种图。
（3）事务图
事务图描述了整个脚本执行过程中的事务性能和状态，主要包括：平均事务响应时间图、每秒事务数图、每秒事务总数、事务摘要图、事务性能摘要图、事务响应时间（负载下）图、事务响应时间（百分比）图和事务响应时间（分布）图。
1、Transation Sunmmary（事务综述） 对事务进行综合分析是性能分析的第一步，通过分析 时间内用户事务的成功与失败情况，
可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间） “事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，
通过它可以分析测试场景运行期间应用系统的性能走向。 例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、Transactions Per Second（每秒通过事务数/TPS） “每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。
分析TPS主要是看曲线的性能走向。 将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。 例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，
很有可能是服务器开始出现瓶颈。
4、Total Transactions Per Second（每秒通过事务总数） “每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、
失败的事务总署以及停止的事务总数。
5、Transaction Performance Sunmmary（事务性能摘要） “事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，
可以直接判断响应时间是否符合用户的要求。 重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，
需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载） “事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，
通过它可以看出在任一时间点事务响应时间与用户数目的关系，
从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。
此图可以查看虚拟用户负载对执行时间的总体影响，
对分析具有渐变负载的测试场景比较有用。
7、Transaction Response Time(Percentile)（事务响应时间(百分比)） “事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，
也就是工具通过一些统计分析方法间接得到的图表。
通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
8、Transaction Response Time(Distribution)（事务响应时间(分布)） “事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，
通过它可以了解测试过程中不同响应时间的事务数量。
如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，
则可以使用此图确定服务器性能是否在可以接受的范围内。
（4）Web资源图
Web资源图主要提供有关Web服务器性能的一些信息，使用Web资源图可以分享方案运行期间每秒点击次数、服务器的吞吐量、从服务器返回的HTTP状态代码、每秒HTTP响应数、每秒页面下载数、每秒服务器重试次数、服务器重试摘要、连接数和每秒连接数。
1、Hits per Second（每秒点击次数） “每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。 通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，
可以查看点击次数对事务性能产生的影响。
通过对查看“每秒点击次数”，可以判断系统是否稳定。
系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
2、Throughput（吞吐率） “吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，
表示虚拟用在任何给定的每一秒从服务器获得的数据量。 可以依据服务器的吞吐量来评估虚拟用户产生的负载量，
以及看出服务器在流量方面的处理能力以及是否存在瓶颈。 “吞吐率”图和“点击率”图的区别： “点击率”图，是每秒服务器处理的HTTP申请数。 “吞吐率”图，是客户端每秒从服务器获得的总数据量。
Throughput(MB)单位是M
Throughput单位是字节
3、HTTP Status Code Summary（HTTP状态代码概要） “HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。
4、HTTP Responses per Second（每秒HTTP响应数） “每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，
也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。
5、Pages Downloaded Per Second（每秒下载页面数） “每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。
使用此图可依据下载的页数来计算Vuser生成的负载量。 和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）
而每秒下载页面数只考虑页面数。 注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。
6、Retries per Second（每秒重试次数） “每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。 在下列情况将重试服务器连接： A、初始连接未经授权 B、要求代理服务器身份验证 C、服务器关闭了初始连接 D、初始连接无法连接到服务器 E、服务器最初无法解析负载生成器的IP地址
7、Retries Summary（重试次数概要） “重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，
它按照重试原因分组。
将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。
8、Connections（连接数） “连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。 借助此图，可以知道何时需要添加 连接。 例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
9、Connections Per Second（每秒连接数） “每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。 理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。
通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。
10、SSLs Per Second（每秒SSL连接数） “每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL
连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。
（5）网页细分图
网页细分图主要是提供一些信息来评估页面内容时否影响事务响应时间，如果出现影响事务响应时间的情况，可以通过细分图进一步分析时什么原因影响网页事务响应时间的。包括网页细分、页面组件细分、页面组件细分（随时间变化）、页面下载时间细分、页面下载时间细分（随时间变化）和已下载组件图几种。
1、Web Page Diagnostics（页面分解总图） “页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。 “页面分解”图可以按下面四种方式进行进一步细分： 1)、DownloadTime Breaddown（下载时间细分） “下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。 2)、ComponentBreakdown(Over Time)（组件细分(随时间变化)） “组件细分”图显示选定网页的页面组件随时间变化的细分图。
通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。
该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。 3)、DownloadTime Breakdown(Over Time)（下载时间细分(随时间变化)） “下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。 “下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，
两者分别从宏观和微观角度来分析页面元素的下载时间。4)、Timeto First Buffer Breakdown(Over Time)
（第一次缓冲时间细分(随时间变化)） “第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲
之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（
以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。 First Buffer Time：是指客户端与服务器端建立连接后，
从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，
到浏览器接收到第一个缓冲所用的时间。
3、Page Component Breakdown（页面组件细分） “页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。
可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。
4、Page Component Breakdown(Over Time)（页面组件分解(随时间变化)） “页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页
及其组件的平均响应时间 （以秒为单位）。
5、Page Download Time Breakdown（页面下载时间细分） “页面下载时间细分”图显示每个页面组件下载时间的细分，
可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。 “页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、
SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载
过程进行细分。
6、Page Download Time Breakdown(Over Time)（页面下载时间细分(随时间变化)） “页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件
下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。 “页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”
图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，
进而定位原因在哪里。
7、Time to First Buffer Breakdown（第一次缓冲时间细分） “第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，
则可以使用此图确定产生的问题与服务器有关还是与网络有关。 网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。 服务器时间：定义为从收到初始HTTP请求确认开始，
直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。
8、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)） “第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一
个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。
可以使用此图确定场景运行期间服务器或网络出现问题的时间点。
9、Downloader ComponentSize(KB)（已下载组件大小） “已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。
（6）系统资源图
系统资源图主要监控场景运行期间系统资源使用率的情况。可以监控Windows资源、UNIX资源、SNMP资源、Antara FlameThrower资源和SiteScope资源。
（7）Web服务器资源图
Web服务器资源图主要用来捕捉场景运行时Web服务器的信息，主要用来分析Microsoft IIS服务器、Apache服务器、iPlanet/Netscape服务器和iPlanet（SNMP）服务器。
（8）数据库服务器资源图
数据库服务器资源图主要显示数据库服务器的统计信息。目前支持DB2、Oracle、SQL Server和Sybase数据库。
1.平均事务响应时间
Average Transation Response Time 优秀：<2s
良好：2-5s
及格：6-10s
不及格：>10s
2.每秒点击率
Hits per Second
当增大系统的压力（或增加并发用户数）时，吞吐率和TPS的变化曲线呈大体一致，则系统基本稳定。若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓 慢，甚至平坦，很可能是网络出现带宽瓶颈，同理若点击率/TPS曲线出现变化缓慢或者平坦，很可能是服务器响应时间增加，观察服务器资源使用情况，确定是 否是服务器问题。
3.请求响应时间
Time to Last Byte：繁琐的业务，一般在15s之内；登录的响应时间多数在3s之内；添加数据的响应时间在8s之内；打开页面在5s之内。
4.每秒系统处理事务数
Transaction per second
5.吞吐量
Throughout
6.CPU利用率
Processor / %Processor Time 好：70%
坏：85%
很差：90%+
7.数据库操作消耗的CPU时间
Processor / %User Time 如果该值较大，可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器，Processor\%User Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。
8.核心态CPU平均利用率
Processor /%Privileged Time如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统
9.处理队列中的线程数
Processor / Processor Queue Length如果该值保持不变（>=2）个并且%Processor Time 超过90%，那么可能存在处理器瓶颈。如果发现超过2，而处理器的利用率却一直很低，那么或许更应该去解决处理器阻塞问题，这里处理器一般不是瓶颈。
10.文件系统缓存
Memory / Cache Bytes 50%的可用物理内存
11.剩余的可用内存
Memory / Avaiable Mbytes至少要有10% 的物理内存值
12.每秒下载页数
Memory / pages/sec 好：无页交换
坏：CPU每秒10个页交换
很差：更多的页交换
13.页面读取操作速率
Memory / page read/sec 如果页面读取操作速率很低，同时% Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
14.物理磁盘利用率
Physical Disk / %Disk Time 好：<30%
坏：<40%
很差：<50%+
15.物理磁盘平均磁盘I/O队列长度
Physical Disk / Avg.Disk Queue Length该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘
16.网络吞吐量
Network Interface / Bytes Total/sec 判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽，结果应该小于50%
17.数据高速缓存区命中率 命中率应大于0.90最好
共享区库缓存区命中率 命中率应大于0.99
监控SGA 中字典缓冲区的命中率 命中率应大于0.85
检测回滚段的争用 小于1%
监控SGA 中重做日志缓存区的命中率应该小于1%
监控内存和硬盘的排序比率 最好使它小于10%
