loadrunner中各性能指标解释
- 格式:docx
- 大小:15.79 KB
- 文档页数:3
MemoryAvailable Mbytes可用物理内存数pages/sec由于硬件页面错误而从磁盘取出的页面数page read/sec页的硬故障Page Faults/sec处理器中的页面错误的计数Pool Nonpaged Bytes在分页池中的字节数Physical Disk% Disk Time 所选磁盘驱动器忙于为读或写入请求提供服务所Avg.Disk Queue Length 读取和写入请求(为所选磁盘在实例间隔中列队的)的平均Average Disk Read/Write Queue Length指读取(写入)请求(列队)的平均数。
Average Disk sec/Read指以秒计算的在此盘上读取数据的所需平均时间。
Average Disk sec/Transfer反映磁盘完成请求所用的时间,指以秒计算的在此Avg.Disk Bytes/TransferDisk Bytes/sec磁盘系统的吞吐率Current Disk Queue Length 在收集操作数据时在磁盘上未完成的请求的数目Processor%Processor Time如果该值持续超过95%,表明瓶颈是CPU%User Time表示耗费CPU的数据库操作,如排序%Privileged Time(CPU内核时间)是在特权模式下处理线程执行代码所花时% DPC TimeServer Work Queues\ Queue LengthSystem\ Processor Queue Length用于瓶颈检测Interrupts/sec测量来自输入/输出 (I/O) 设备的服务请求的速度Objects\Threads计算机在收集数据时的线程数System\File Data Operations计算机对文件系统设备执行读取和写入操作的速率。
这不process\Private Bytes此进程所分配的无法与其它进程共享的当前字节数量Network InterfaceBytes Total/sec发送和接收字节的速率,包括帧字符在内包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。
Loadrunner 性能指标定位系统瓶颈判定cpu瓶颈1, %processor time平均值大于952,processor queue length大于2 (大于处理器个数+1).可以确定cpu瓶颈3, cpu空闲时间为零(zero percent idle cpu)4,过高的用户占用cpu时间(%user time)5, 过高的系统占用cpu时间(%priviliaged time:长期大于90%或者95%)备注:%user time(processor_total)表示耗费cpu的数据库操作,如排序,执行agg regate functions等。
假如该值很高,可考虑增加索引,尽量使用简单的表联接,水平分割大表格等方法来降低该值假如发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈。
判定内存瓶颈与内存泄漏1,假如发生了内存泄漏,process\private bytes计数器和process\working s et计数器的值往往会升高,同时avaiable bytes的值会降低。
2,假如available mbytes(剩余物理内存数)的值很小(4 mb 或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。
定位磁盘瓶颈1, % disk time和avg.disk queue length 的值 (应不大于组成物理磁盘的主轴数的 1.5 到2倍) 很高,而page reads/sec页面读取操作速率很低,则可能存在磁盘瓶径。
2,physical disk\ disk reads/sec and disk writes/sec大于20 ms,则有可能磁盘瓶颈3,avg.disk sec/transfer盘中写入数据的平均时间,单位是秒,一般来说,定义该值小于15ms最为优异,介于15-30ms之间为良好,30-60ms之间为可以接受,超过60ms则需要考虑更换硬盘或硬盘的raid方式了4,disk transfers/sec指在此盘上读取/写入操作速率。
性能测试指标参考目录1术语 (2)1.1响应时间 (2)1.2并发用户数 (2)1.3在线用户数 (2)1.4吞吐量 (3)2 Vuser图 (3)2.1 “运行Vuser ”图(Running Vusers) (3)2.2 “集合”图(Rendezvous) (3)3 错误图 (3)3.1 “每秒错误数(按描述)”图(Error Statistics) (3)4 事务图 (4)4.1 “平均事务响应时间”图(Average Transaction Response Time) (4)4.2“负载下的事务响应时间”图(Running Vuser –Average Transaction Response Time) (4)4.3“页面细分”图(Web Page Diagnostics图) (5)4.4“每秒事务数”(Transactions per second 简称:TPS) (6)5 Web资源图 (6)5.1“每秒点击次数”图(Hits per Second) (6)5.2“吞吐量”图(Throughput) (6)6 系统资源图 (6)6.1 LoadRunner下监控的UNIX资源指标 (6)6.1.1平均负载(Average load) (6)6.1.2 CPU利用率(CPU utilization) (7)6.1.3 每秒传入的包数(Paging rate) (7)6.2使用NMON工具监控Linux资源 (7)6.2.1 系统资源汇总(SYS_SUMM) (7)6.2.2 磁盘资源汇总(DISK_SUMM) (8)6.2.3 内存资源(MEM) (8)7 网络监控器图 (9)7.1 “网络延迟时间”图(Network Delay Time) (9)8 数据库服务器资源图 (10)8.1 Oracle服务器监控度量 (10)8.1.1 添加Oracle自定义计数器 (11)8.1.2 性能分析工具Statspack所提供的性能分析指标 (15)8.2 SQL Server服务器监控度量 (18)1术语1.1响应时间响应时间是从请求到响应所需时间,从客户端请求开始,结束于来自服务器的响应并呈现页面的时间。
LoadRunner11性能测试1.概要介绍1.1.软件性能介绍性能是一种指标,表明软件系统或构件对于其及时性要求的符合程度;同时也是产品的特性,可以用时间来进行度量。
表现为:对用户操作的响应时间;系统可扩展性;并发能力;持续稳定运行等。
1.2.软件性能的主要技术指标Average Transaction Response Time:事务平均响应时间;Tps:每秒事务处理量(TransactionPerSecond);响应时间:响应时间=呈现时间+系统响应时间;吞吐量:单位时间内系统处理的客户请求数量(请求数/秒,页面数/秒,访问人数/秒);并发用户数:业务并发用户数。
1.3.LoadRunner介绍LoadRunner是HP公司(原MERCURY公司)推出的一种预测系统行为和性能的负载测试工具。
通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner能够对整个企业架构进行测试。
通过使用LoadRunner,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。
LoadRunner是一种适用于各种体系架构的自动负载测试工具,它能预测系统行为并优化系统性能。
LoadRunner的测试对象是整个企业的系统,它通过模拟实际用户的操作行为和实行实时性能监测,来帮助您更快的查找和发现问题。
此外,LoadRunner能支持广泛的协议和技术,为您的特殊环境提供特殊的解决方案。
1.4.LoadRunner工具组成虚拟用户脚本生成器:捕获最终用户业务流程和创建自动性能测试脚本,即我们在以后说的产生测试脚本;压力产生器:通过运行虚拟用户产生实际的负载;用户代理:协调不同负载机上虚拟用户,产生步调一致的虚拟用户;压力调度:根据用户对场景的设置,设置不同脚本的虚拟用户数量;监视系统:监控主要的性能计数器;压力结果分析工具:本身不能代替分析人员,但是可以辅助测试结果的分析。
1.5.LoadRunner工具原理代理(Proxy)是客户端和服务器端之间的中介人,LoadRunner就是通过代理方式截获客户端和服务器之间交互的数据流。
LoadRunner性能测试指标分析·Memory:·Available Mbytes简述:可用物理内存数.如果Available Mbytes的值很小(4 MB或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。
参考值:4 MB或更小,至少要有10%的物理内存值·Page/sec (Input/Out)简述:为了解析硬页错误,从磁盘取出或写入的页数。
一般如果Page/sec持续高于几百,那么您应该进一步研究页交换活动。
有可能需要增加内存,以减少换页的需求(你可以把这个数字乘以4k就得到由此引起的硬盘数据流量)。
Pages/sec的值很大不一定表明内存有问题,而可能是运行使用内存映射文件的程序所致。
参考值:·Page Fault简述:处理器每秒处理的错误页(包括软/硬错误)。
当处理器向内存指定的位置请求一页(可能是数据或代码)出现错误时,这就构成一个Page Fault。
如果该页在内存的其他位置,该错误被称为软错误(用Transition Fault/sec记数器衡量);如果该页必须从硬盘上重新读取时,被称为硬错误。
许多处理器可以在有大量软错误的情况下继续操作。
但是,硬错误可以导致明显的拖延。
参考值:·Page Input/sec简述:为了解决硬错误页,从磁盘上读取的页数。
参考值:·Page reads/sec简述:为了解决硬错误页,从磁盘上读取的次数。
解析对内存的引用,必须读取页文件的次数。
阈值为>5.越低越好。
大数值表示磁盘读而不是缓存读。
参考值:·Cache Bytes简述:文件系统缓存,默认情况下为50%的可用物理内存。
如IIS5.0运行内存不够时,它会自动整理缓存。
需要关注该计数器的趋势变化。
该指标只显示最后一次观察的值,它不是一个平均值。
参考值:·pool paged bytes简述: 指在分页池中的字节数,分页池是系统内存中可供对象使用的一个区域。
Transactions(用户事务分析)用户事务分析是站在用户角度进行的基础性能分析。
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(事务响应时间与负载)“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合,通过它可以看出在任一时间点事务响应时间与用户数目的关系,从而掌握系统在用户并发方面的性能数据,为扩展用户系统提供参考。
51Testing 软件测试论坛 » [LoadRunner] » 关于LoadRunner 参数的详细解释(自己看的)[转贴] 关于LoadRunner 参数的详细解释(自己看的)1# 大 中 小 发表于 2010-6-18 10:05 只看该作者关于LoadRunner 参数的详细解释(自己看的)通过创建表方式和数据向导方式都可以成功创建数据文件,操作员可以随意选择自己习惯的方式。
总之,能坚守数据文件放数据的原则,就不会出问题了。
当回到“参数属性页面”中后,发现数据已经准备好了,而且原来灰色的区域目前也可以选择了。
“选择下一行”共有下面几个选项:Sequential :按照顺序一行行的读取。
每一个虚拟用户都会按照相同的顺序读取。
Random :任意选择。
但是在每一次迭代中,将不发生变化。
Unique :唯一的数。
当使用该选项时,需要保证准备的数据文件中有足够的数据。
比如要做20个虚拟用户,每个用户要进行5次迭代,第一个用户在5次迭代中分别使用数据文件中的数据1~数据5,第二个用户在5次迭代中分别使用数据文件中的数据6~数据10,类推以后20个用户将使用到100个数据。
那么必须保证准备的数据文件中有100个以上的数据,否则运行时会出错。
Same line as 某个参数:和前面定义的参数取同行的记录。
通常用在有关联性的数据上面。
比如当我做登录密码的参数化时,由于它和UserID 是有关联的,所以会用到这种选择方式。
“更新值的时间”共有下面几个选项:Each iteration :每次迭代更新一个新的值。
Each occurrence :每次出现时该参数时更新一个新的值。
Once不管迭代多少次该参数的值一直保持不变。
*****注意*****1、参数类型:在创建参数的时候,我选择了参数类型为File。
参数类型共有9种,现在来简单介绍一下所有的参数类型以及意义。
1.1、DateTime:在需要输入日期/时间的地方,可以用DateTime 类型来替代。
LoadRunner报告分析报告1. 引言本文将对LoadRunner的报告进行详细分析,帮助读者了解应用测试的性能瓶颈和优化方向。
LoadRunner是一款常用的性能测试工具,通过模拟真实用户的行为对系统进行压力测试,从而评估系统的性能和可靠性。
2. 报告概览在本节中,我们将对LoadRunner报告的整体概况进行分析。
报告包括以下几个关键指标:2.1 响应时间分析LoadRunner报告提供了每个请求的平均响应时间、最大响应时间和最小响应时间等指标。
通过对这些指标的分析,我们可以了解系统在不同负载下的响应情况。
2.2 事务响应时间分布LoadRunner报告还提供了事务响应时间的分布情况。
通过观察事务响应时间的分布情况,我们可以了解系统中存在的性能瓶颈和优化的空间。
2.3 错误分析LoadRunner报告中的错误分析可以帮助我们定位系统中出现的错误,并分析错误的原因。
通过对错误的分析,我们可以找到系统中的问题,并提出相应的解决方案。
3. 响应时间分析在这一节中,我们将对LoadRunner报告中的响应时间进行详细分析。
通过对响应时间的分析,我们可以了解系统在不同压力下的性能表现。
3.1 平均响应时间平均响应时间是衡量系统性能的重要指标之一。
根据报告显示的平均响应时间,我们可以了解系统对用户请求的平均处理时间。
如果平均响应时间过长,说明系统的性能存在问题,需要进一步优化。
3.2 最大响应时间最大响应时间是指系统处理用户请求的最长时间。
通过分析最大响应时间,我们可以找到系统中存在的性能瓶颈。
如果最大响应时间过长,可能会导致用户体验不佳,需要优化系统的性能。
3.3 最小响应时间最小响应时间是指系统处理用户请求的最短时间。
通过分析最小响应时间,我们可以了解系统在轻负载下的性能表现。
如果最小响应时间过长,可能会导致用户等待时间增加,需要优化系统的性能。
4. 事务响应时间分布在这一节中,我们将对LoadRunner报告中的事务响应时间分布进行分析。
1、Transactions(用户事务分析)用户事务分析是站在用户角度进行的基础性能分析。
1.1、TransationSunmmary(事务综述)对事务进行综合分析是性能分析的第一步,通过分析测试时间内用户事务的成功与失败情况,可以直接判断出系统是否运行正常。
1.2、Average Transaciton Response Time(事务平均响应时间)“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间,通过它可以分析测试场景运行期间应用系统的性能走向。
例:随着测试时间的变化,系统处理事务的速度开始逐渐变慢,这说明应用系统随着投产时间的变化,整体性能将会有下降的趋势。
1.3、Transactions per Second(每秒通过事务数/TPS)“每秒通过事务数/TPS”显示在场景运行的每一秒钟,每个事务通过、失败以及停止的数量,是考查系统性能的一个重要参数。
通过它可以确定系统在任何给定时刻的时间事务负载。
分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比,可以分析事务数目对执行时间的影响。
例:当压力加大时,点击率/TPS曲线如果变化缓慢或者有平坦的趋势,很有可能是服务器开始出现瓶颈。
1.4、Total Transactions per Second(每秒通过事务总数)“每秒通过事务总数”显示在场景运行时,在每一秒内通过的事务总数、失败的事务总数以及停止的事务总数。
1.5、Transaction Performance Sunmmary(事务性能摘要)“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间,可以直接判断响应时间是否符合用户的要求。
重点关注事务的平均和最大执行时间,如果其范围不在用户可以接受的时间范围内,需要进行原因分析。
1.6、Transaction Response Time Under Load(事务响应时间与负载)“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合,通过它可以看出在任一时间点事务响应时间与用户数目的关系,从而掌握系统在用户并发方面的性能数据,为扩展用户系统提供参考。
加大:在tomcat配置文件server.xml中的配置中,和连接数相关的参数有:minProcessors:最小空闲连接线程数,用于提高系统处置性能,默许值为10maxProcessors:最大连接线程数,即:并发处置的最大请求数,默许值为75acceptCount:许诺的最大连接数,应大于等于maxProcessors,默许值为100enableLookups:是不是反查域名,取值为:true或false。
为了提高处置能力,应设置为false connectionTimeout:网络连接超时,单位:毫秒。
设置为0表示永不超时,如此设置有隐患的。
通常可设置为30000毫秒。
其中和最大连接数相关的参数为maxProcessors和acceptCount。
若是要加大并发连接数,应同时加大这两个参数。
server许诺的最大连接数还受制于的内核参数设置,通常是2000个左右,Linux是1000个左右。
weblogic 整合参数(二)可以制作自己的错误响应页面,在Web服务器不能将请求代理到服务器时使用。
设置该的方式有两种:作为相对URI(文件名)。
插件自动将返回错误的Web的上下文路径加到URI中。
对错误页面的请求是否回代理到服务器取决于你对代理的配置(是MIME类型式代理还是路径式代理)。
作为绝对URI(建议)。
使用错误页面的绝对路径能够使请求总是被代理到服务器中的正确资源上。
例如:http://host:port/myWebApp/ErrorPage.html二、连接池实现下面给出连接池类和连接池治理类的要紧属性及所要实现的大体接口:public class DBConnectionPool implements TimerListener{private int checkedOut;//已被分派出去的连接数private ArrayList freeConnections = new ArrayList();//容器,空闲池,依照//创建时刻顺序寄存已创建但尚未分派出去的连接private int minConn;//连接池里连接的最小数量private int maxConn;//连接池里许诺存在的最大连接数private String name;//为那个连接池取个名字,方便治理private String password;//连接数据库时需要的密码private String url;//所要创建连接的数据库的地址private String user;//连接数据库时需要的用户名public Timer timer;//按时器public DBConnectionPool(String name, String URL, String user, Stringpassword, int maxConn)//公布的构造函数public synchronized void freeConnection(Connection con) //利用完毕以后,//把连接返还给空闲池public synchronized Connection getConnection(long timeout)//取得一个连接,//timeout是等待时刻public synchronized void release()//断开所有连接,释放占用的系统资源private Connection newConnection()//新建一个数据库连接public synchronized void TimerEvent() //按时器事件处置函数}public class DBConnectionManager {static private DBConnectionManager instance;//连接池治理类的唯一实例static private int clients;//客户数量private ArrayList drivers = new ArrayList();//容器,寄存数据库驱动程序private HashMap pools = new HashMap ();//以name/value的形式存取连接池//对象的名字及连接池对象static synchronized public DBConnectionManager getInstance()//若是唯一的//实例instance已经创建,直接返回那个实例;不然,挪用私有构造函数,创//建连接池治理类的唯一实例private DBConnectionManager()//私有构造函数,在其中挪用初始化函数init()public void freeConnection(String name, Connection con)// 释放一个连接,//name是一个连接池对象的名字public Connection getConnection(String name)//从名字为name的连接池对象//中取得一个连接public Connection getConnection(String name, long time)//从名字为name//的连接池对象中取得一个连接,time是等待时刻public synchronized void release()//释放所有资源private void createPools(Properties props)//依照属性文件提供的信息,创建//一个或多个连接池private void init()//初始化连接池治理类的唯一实例,由私有构造函数挪用private void loadDrivers(Properties props)//装载数据库驱动程序}3、连接池利用上面所实现的连接池在程序开发时如何应用到系统中呢?下面以Servlet为例说明连接池的利用。
1. Windows性能计数器分析对象计数器分析Processor%processor time 建议阈值85%memoryA vailable bytes建议阈值少于4MB需要添加内存;另外,又建议至少要有10%的物理内存值Pages reads/secPage Reads/sec 是指为解析硬页错误而读取磁盘的次数,如果该值一直持续较大,表明可能内存不足建议阈值30(5?),大数值表示磁盘读而不是缓存读Pages writes/secPage Writes/sec 是指为了释放物理内存空间而将页写入磁盘的次数Pages Input/secPages Input/sec 指为解决页错误从磁盘上读取的页数Pages Output/secPages Output/sec 是指为了释放物理内存空间而写入磁盘的页数如果该值远远大于Pages Input/sec,可能有内存泄露Pages/secPages/sec 是指为解析硬页错误从磁盘读取或写入磁盘的页数建议阈值20Network interface(对于TCP/IP)Bytes received/sec该数据结合Bytes total/sec看Bytes sent/sec该数据结合Bytes total/sec看Bytes total/sec推荐不要超过带宽的50%Packets/sec根据实际数据量大小,无建议阈值,该数据结合Bytes total/sec看Physical diskDisk reads/sec取决于硬盘制造商的规格,检查磁盘的指定传送速度,以验证此速度没有超出规格Disk writes/sec取决于硬盘制造商的规格,检查磁盘的指定传送速度,以验证此速度没有超出规格又:上两值相加,应小于磁盘设备的最大容量%Disk Time建议阈值90%Current disk queue lengthA vg. disk queue length(如果使用RAID设备,%Disk Time计数器显示的值可以大于100%。
LoadRunner 结果分析报告1. 引言在软件开发的过程中,性能测试是一个至关重要的环节。
性能测试能够帮助我们评估系统的负载能力、稳定性和响应时间等关键指标。
本文将通过分析LoadRunner 测试结果来评估系统的性能表现,为进一步的优化提供指导。
2. 测试背景在进行结果分析之前,首先需要了解测试背景。
我们在一个电子商务平台上进行了性能测试,模拟了多个用户同时访问系统的情况。
测试目的是评估系统在高负载下的性能表现,并发现潜在的性能问题。
3. 测试设计在进行性能测试之前,需要明确测试的设计。
我们使用了 LoadRunner 这一常用的性能测试工具。
测试设计主要包括测试场景的设置、虚拟用户的模拟和测试数据的准备等。
3.1 测试场景设置我们选择了一些常见的用户行为作为测试场景,包括登录、浏览商品、添加购物车和下单等。
这些场景模拟了用户在电商平台上的典型行为。
3.2 虚拟用户模拟为了模拟真实的用户场景,我们使用了 LoadRunner 提供的虚拟用户功能。
通过设置虚拟用户的数量和行为,我们可以模拟多个用户同时访问系统的情况。
3.3 测试数据准备为了模拟真实的情况,我们需要准备一些测试数据。
这些数据包括用户信息、商品信息和订单信息等。
通过使用真实的数据,我们可以更准确地评估系统的性能。
4. 测试结果分析在进行性能测试后,我们得到了一系列的测试结果数据。
下面将详细分析这些数据,以评估系统的性能表现。
4.1 吞吐量分析吞吐量是衡量系统性能的重要指标之一,它表示在单位时间内系统处理的请求数量。
我们通过 LoadRunner 的结果数据计算出了系统在不同负载下的吞吐量,并绘制成图表进行分析。
4.2 响应时间分析响应时间是用户感知系统性能的关键指标,它表示用户发送请求到系统返回结果的时间。
我们通过 LoadRunner 的结果数据计算出了系统在不同负载下的平均响应时间,并绘制成图表进行分析。
4.3 错误率分析错误率是衡量系统稳定性的指标之一,它表示系统在处理请求时出现错误的比率。
LoadRunner:性能测试的工具1.性能测试:通过自动化的测试工具模拟多种正常、峰值以及异常负载条件对系统的各项性能指标进行测试。
性能测试时从性能和整体的角度研究日趋复杂的应用系统的质量问题。
2.负载测试和压力测试都属于性能测试。
3.负载测试(Load Testing):通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。
4.压力测试(Stress Testing):是在强负载(大数据量、大量并发用户)下的测试,查看应用系统在峰值使用情况下的操作行为,从而有效地发现系统的某项功能隐患、系统是否具有良好的可恢复能力。
5.稳定性压力测试:高负载下的长时间(如24小时以上)测试6.破坏性压力测试:极限情况下导致系统崩溃7.自动负载测试:通过在一台或几台PC机上模拟成百上千的虚拟用户同时执行业务的情况。
【Mission-critical:关键使命】8.数据大集中的优点:(1)加强控制,降低风险(2)减少IT开支【典型的企业信息系统:】A客户端——B网络——C应用服务器——D数据库服务器总处理时间T = T1 + T2+ T3T1: 网络延迟时间T2: 应用服务器处理时间T3: 数据库服务器处理时间9.性能测试的原理:性能测试就是模拟出多个人同时向服务器发出请求。
10.手工性能测试的局限性:人力物力同步性差可重复性差11.自动化性能测试工具LoadRunner:利用计算机的多进程和多线程的特性,让多个进程或多个线程同时进行,同时向后台发送请求,我们把这些进程或线程称之为Virtual User.Virtual User,虚拟用户Controller,协调员,控制器12.进程:是指在系统中正在运行的一个应用程序;13.线程:是系统分配处理器时间资源的基本单位,或者说是进程之内独立执行的一个单元。
14.自动化性能测试的优点:(1)节省了大量的人力和物力(2)有统一的集中控制器(3)重复测试成本低(4)可以把后天的压力结果搜集到一个地方然后由统一的分析器对这个结果进行分析15.LoadRunner是一个Windows平台的软件,其组件:(1)Vugen(Virtual User Generator)虚拟用户生成器(即Vugen脚本生成器:可以和被测系统连接起来):提供了一个录制功能,这个录制功能就是操作的时候把操作录制下来,这个操作包括向后台发送的请求包和响应包,然后转换为测试脚本的形式,然后去回放这个测试脚本,它所做的请求对后台实施的压力和动手操作的时候没有任何区别。
Transactions(用户事务分析)
用户事务分析是站在用户角度进行的基础性能分析。
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)(事务响应时间(分布))
“事务响应时间(分布)”显示在场景运行过程中,事务执行所用时间的分布,通过它可以了解测试过程中不同响应时间的事务数量。
如果系统预先定义了相关事务可以接受的最小和最大事务响应时间,则可以使用此图确定服务器性能是否在可以接受的范围内。
Web Resources(Web资源分析)
Web资源分析是从服务器入手对Web服务器的性能分析。
1、Hits per Second(每秒点击次数)
“每秒点击次数”,即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量,如将其和“平均事务响应时间”图比较,可以查看点击次数对事务性能产生的影响。
通过对查看“每秒点击次数”,可以判断系统是否稳定。
系统点击率下降通常表明服务器的响应速度在变慢,需进一步分析,发现系统瓶颈所在。
2、Throughput(吞吐率)
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。
其度量单位是字节,表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量,以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
“吞吐率”图和“点击率”图的区别:
“吞吐率”图,是每秒服务器处理的HTTP申请数。
“点击率”图,是客户端每秒从服务器获得的总数据量。
3、HTTP Status Code Summary(HTTP状态代码概要)
“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数,该图按照代码分组。
HTTP状态代码表示HTTP请求的状态。
4、HTTP Responses per Second(每秒HTTP响应数)
“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量,还能返回其它各类状态码的信息,通过分析状态码,可以判断服务器在压力下的运行情况,也可以通过对图中显示的结果进行分组,进而定位生成错误的代码脚本。
5、Pages Downloader 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连接。
Web Page Breakdown(网页元素细分)
“网页元素细分”主要用来评估页面内容是否影响事务的响应时间,通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
元素。
1、Web Page Breakdown(页面分解总图)
“页面分解”显示某一具体事务在测试过程的响应情况,进而分析相关的事务运行是否正常。
“页面分解”图可以按下面四种方式进行进一步细分:
1)、Download Time Breaddown(下载时间细分)
“下载时间细分”图显示网页中不同元素的下载时间,同时还可按照下载过程把时间进行分解,用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2)、Component Breakdown(Over Time)(组件细分(随时间变化))
“组件细分”图显示选定网页的页面组件随时间变化的细分图。
通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。
该图特别适用于需要在客户端下载控件较多的页面,通过分析控件的响应时间,很容易就能发现那些控件不稳定或者比较耗时。