设为首页 | 加入收藏夹

八文网 - 汇聚八方文档 - 做最优秀的免费文档下载网站

了解性能测试的基础

文档类型：

Microsoft Word 文档文档大小：148KB

目标
1,了解性能测试的基础
2,执行负载测试
3,执行压力测试
4,建立工作负载模型
5,识别测试最好和最差的方法预览性能测试是为了识别应用程序能否在期望的和最大的负载条件下运行、并且能标明处理需求增长的能力.有三种看似相似却是实现不同目标的测试类别:
负载测试使用负载测试来检查应用程序在正常情况和最大负载情况下的运行情况.你能从中得出应用程序在正常情况下的性能目标,这些指标用来定义服务的级别.通过负载测试您能测量出响应时间,吞吐量,资源利用水平和应用程序的断点、并且可以评估在最大负载条件下断点怎样发生的.
压力(强度)测试压力测试用来评估在超越最大负载的情况下系统将如何运行.压力测试的目标就是发现在高负载的条件下应用程序的缺陷(BUG).包括 issues, race conditions, and memory leaks(内存泄漏).压力测试能让您识别程序的弱点和在极限负载下程序将如何运行.
容量测试容量测试是负载测试的补充用来测定程序最终的破裂点(failure point),而负载测试是监视在各种负载情况下的结果.在制定容量计划的同时进行容量测试.容量计划为了适应未来的需求增长,例如用户的增长或是数据的增长.举个例子来说,为了适应未来的负载,你需要了解需要多少资源来支持未来的使用等级.容量测试能够帮助您指定一个等级策略,用来判断该如何增加或减少相应的资源.
性能测试性能测试的过程就是识别应用程序对一系列的条件和输入如何响应的过程.性能测试中的多个独立的场景需要包括所有的条件和输入影响.如果可能,性能测试应该在现实环境中具有代表意义的主机上进行.通过在多个负载环境下的测试,你能识别应用程序是趋向还是远离被定义的性能指标.
性能测试的目标性能测试最主要的目标就是了解系统如何运行能更好的达到性能指标.性能测试的其它目标包括以下几点:识别系统瓶颈和产生瓶颈的原因最优化和调整平台的配置(包括硬件和软件)来达到最高的性能在压力测试下验证程序的可靠性不可能只通过一种单一类型的测试来识别所有的性能参数.以下是一些性能参数:响应时间(Response time)吞吐量(Throughput)最大并发用户(Maximum concurrent users supported)资源需求.包括CPU数,内存,网络IO,硬盘IO在各种负载条件下的运行情况,包括正常情况,极限情况和介于两种情况之间的情况应用程序的断点程序断点是指系统停止对请求响应的条件.在压力条件下系统崩溃的现象和原因程序的弱点应准备什么来满足有计划增长的负载需求例如增长的用户,增长的数据量和应用程序使用频率的变化导致的负载性能目标大多数的性能测试是基于一系列的预定义的,文档的和对性能指标意见一致的基础上的.一开始就了解这些性能指标能使测试的过程更有效.通过比较性能参数你能计算出系统的性能.
性能参数通常有以下几种:响应时间(Response time or latency)资源需求(Resource utilization)工作负载(Workload)响应时间是指当一个请求发生到它接收到响应的时间.你可以测试在服务器上和在客户端上的响应时间.
服务器端的响应时间(Latency measured at the server) 这个时间指的是服务器完成请求执行的时间,不包括客户端到服务器端的反应(请求和反应在网络上的通讯时间)
客户端的响应时间(Latency measured at the client) 这个反应时间等于客户端的请求队列加上服务器的反应时间和网络的反应时间.你可以用各种各样的方法来测试反应时间.常用的有两种方法:首字节响应时间(度量首字节的响应时间,指向服务器发送请求与接收到响应的第一个字节之间的时间)和末字节响应时间(度量末字节的响应时间,指向服务器发送请求与接收到响应的最后一个字节之间的时间.)通过测量反应时间,您能知道您的应用程序是否因为响应时间太久以至于不能响应请求.
吞吐量是指您的应用程序在每单位时间内能响应多少个请求.它由负载(如用户的数量)或使用什么类型的应用程序来决定.举个例子,下载文件比浏览网页需要更高的吞吐量.吞吐量通常用来衡量每秒的请求数,还有其它的衡量单位、例如每秒的事物处理数或每秒的指令数.
资源需求根据服务器和网络的资源来识别资源需求的成本.主要的资源有:CPU内存磁盘IO网络IO您能识别每个基本操作的资源成本.这些操作包括浏览一个产品分类,添加一项购物车或是下一个订单.您可以测量一个用户负载情况下的资源成本,也可以平均计算资源成本当使用一个给定的工作负载的模型.
这个工作负载的模型由用户执行一系列不同操作的混合体.例如,有两百个并发用户,其中有20%的用户在进行订单的定购操作,有30%的用户往购物车中添加商品、有50%的用户在浏览产品的分类.这样您就能识别和调整那些消耗服务器资源和响应时间比重异常大的部分.
工作负载在这一节,我们来定义同时在线用户和并发用户的负载情况.同时在线用户是指同一时间和同一个网站连接的用户,而并发用户是指同一时刻点击同一个站点的用户.并发是指基本上不间断的发生.您的站点可能有100到150个并发用户,可是可能有1000到1500个同时在线的用户.
当加载程序测试时,您可以通过在测试脚本中增加等待时间来模拟同时在线用户.
然而您要进行压力测试的时候可以从脚本中删除思考时间.加载测试过程运行负载测试来检查应用程序在正常情况和最大负载情况下的运行情况.您可以慢慢地增量增加负载,从正常负载到最大负载的过程您可以观察应用程序在各个不同的负载阶段的运行情况.您可以一直增加负载直到达到性能指标的阀值.例如您可以加载负载直到CPU的使用率达到75.负载测试过程能让您了解系统的瓶颈和系统的最大的操作容量.
输入性能指标应用程序的特征(场景)工作负载特征每个场景的性能指标测试计划步骤负载测试的过程包括六个步骤,如图一识别关键场景识别对应用程序性能要求苛刻的场景.识别工作负载通过关键场景来分配全部的工作负载.识别计数器识别那些在测试过程中需要收集的计数器创建测试用例根据关键场景来创建测试用例模拟负载使用测试工具来模拟测试用例并获得计数器的结果分析结果分析已获得的计数器的数据.下面我们来详细讨论一下这些步骤步骤一识别关键场景场景是由用户正常执行多个应用活动组成的.这些场景的设计是为了能获得指定的性能目标或能获得重要的性能压力.这些场景的例子如下:登入系统浏览产品目录搜索指定的产品添加商品到购物车验证信用卡并下订单
本次测试选定的EAS系统的关键场景:采购订单的录入和审核、入库单的录入和审核(简称EAS场景一)潜在客户的录入,联系人录入和销售行动的录入(简称EAS场景二)收发存统计(简称EAS场景三)步骤二识别工作负载识别每个定义好的场景的性能特征或工作负载.为每一个场景你都要识别出以下参数:用户数在某个时间段内并发用户和在线用户的总数量.请求的比率指每单位时间(例如每秒)当前并发用户发出的请求.请求的模式当前并发的用户可能执行不同的任务.请求的模式就是识别某个功能模块下用户数和请求数的平均数.
在创建完工作负载模型以后,按照分配好的用户配置文件开始进行测试.在每个测试周期结束后可以增量的增加负载.继续增加负载直到各个资源达到性能目标的峰值.继续增加用户直到达到性能的极限.
EAS系统真实情况EAS系统工作负载我们以100用户的公司为例,调查情况如下每天开采购订单100个,录入潜在客户100个,进行查询300次步骤三识别计数器当您模拟负载的时候,您需要知道哪个计数器需要收集以及在哪收集.识别跟您的系统的性能有关的计数器,并且可以根据这些计数器来识别系统的瓶颈.
当您进行迭代测试的时候,可以增加相应的计数器.为了识别您的系统的性能的更多的细节和潜在的瓶颈,可以对以下类别进行监视:
网络计数器这组计数器提供网络正常和有效运行的信息,例如:路由器,交换机和网关等等系统相关的计数器这组计数器帮助您识别您的服务器的资源利用.这些资源是CPU,内存,磁盘的输入输出和网络的输入输出等.
应用程序计数器服务水平计数器这组计数器能帮助您恒量应用程序的吞吐量和延迟,也可以衡量应用程序可能被哪些场景约束.如表格一:计数器值每秒的订单数每秒浏览的目录树并发的用户数
100 识别计数器后您可以确定正常负载条件下的一个基线.这个基线能帮助您决定您的应用程序能够接受的负载水平.基线值能帮你分析在各个负载水平下您的应用程序的性能.如表格二:
表格二:能够接受的负载水平可接受的值CPU使用率不能超过60%每秒的请求数100或更多客户端的响应时间(TTLB)(56K带宽)不能超过8秒EAS系统能接受的负载水平客户端的响应时间(TTLB)(100M带宽)不能超过1秒平均每秒网络接收和发送的字节不超过5M步骤四创建测试用例
本节通过举例说明:
电子商务例子:用户数500个在线用户测试周期两小时思考时间在脚本里每个操作之间有1~10秒的随机时间根据第二步识别的工作负载进行用户的分配.如表格三用户场景用户百分比用户数浏览搜索下订单Total期望的结果
期望的结果被定义、例如:
当前执行的请求45个请求执行(ASP.NET Applications\Requests Executing performance counter)
平均的响应时间2.5秒的响应时间(TTLB on 100 megabits per second [Mbps] LAN)资源利用的阀值Processor% Processor Time: 75 percentMemory\Available MBytes: 25 percent of total physical RAM用户数100个在线用户每个周期的准备时间半小时思考时间模拟真实情况(EAS场景一用时15分钟,EAS场景二用时15分钟,EAS场景三用时2分钟)
我们设用户的比为X:Y:Z 设测试总时间为T
则有XT15:YT15:ZT2 =计算并调整后得出
第一个测试周期工作负载中用户的分配如表格四场景一40%场景二场景三20%
20 吞吐量每秒请求100个平均响应时间1秒
可用的内存:200M
网络接收和发送的字节:5M以内
第二个测试周期工作负载中用户的分配如表格五
40
第三个测试周期工作负载中用户的分配如表格六
60
第四个测试周期工作负载中用户的分配如表格七
160
第五个测试周期工作负载中用户的分配如表格八步骤五负载模拟使用测试工具例如ACT来运行已识别的场景并模拟负载.除了能处理公共的客户端请求例如身份验证、cookie和view state之外,ACT还允许您同时运行多个测试实例以匹配测试用例.
注意:请确认您用来模拟负载的客户端的机器是没有在重负载的条件下运行.像CPU和内存的使用率都在锋值以下.
EAS负载模拟,测试脚本的制作
1,定义三个常用的全局变量Dim
2,寻找Request对象的Verb的属性为Post的函数,例如:Login.aspx, 在Request对象的Body属性中察看是否有__VIEWSTATE的键值对、如果没有则跳过如果有则向上搜索Request对象的Verb的属性为GET的Login.aspx(可能有多个)
在查到的Login.aspx页面中增加代码:Begin viewstate parsingIf __VIEWSTATE) ThenPos1 = __VIEWSTATE), = , % = , %3D)End IfEnd viewstate parsingGet SalesOrderID created by liujyIf salesOrderID) ThenPos1 = salesOrderID), = PosEnd GetTest.Trace 以上代码用来修改__VIEWSTATE的值,以便为POST页面使用,向下搜索Login.aspx的POST函数在Request对象的Body的值中查找__VIEWSTATE,例子如下:
oRequest.Body = = oRequest.Body s% = oRequest.Body 用变量strViewstate来替换ACT view state GUID,修改后代码如下:oRequest.Body = __VIEWSTATE= = oRequest.Body
3,请保证在一对GET和POST之间没有其它的GET和POST对、如果有请再申明一个全局的view state变量,并重复2步骤
4,如果在POST界面中生成的值(例如:OrderID)不能重复的话、需要将该值用变量来替换, 变量的值可以从前面的函数获得,也可以根据具体情况进行模拟,例如编写代码获得当前的时间等等、代码编写如下:If orderId) ThenPos1 = orderId), = Pos
5,有些变量每次录入的时候都不相同、这样每次测试循环的时候都要改变值,例如客户名称等、加载循环变量,样例代码如下:Dim iDim customNameSub = ruihe_ ,) _i= i)End Sub
6,如果页面信息量太大则需要增加代码 =默认情况下该值为8192字节
7,模拟真实情况,替换http协议版本将 = HTTP1.0替换成 = HTTP1.1
8,脚本中停止测试运行的函数:Call Test.StopTest
9,如果想跟踪或调试错误可以截取页面信息并反映值到日志,代码例子如下:strStatusCode = strStatusCode = 500 ThenTest.Trace Status Code: oResponse.Body
10,注意: ACT工具不允许cookie值为中文,如果程序中有涉及到cookie付值的,请尽量将中文值变成英文值步骤六分析结果分析捕获的数据并和基线数据作比较.您捕获的数据将帮助您分析您的应用程序是否符合您指定的性能目标.
吞吐量响应时间资源利用其它重要的计数器能够帮助您识别和诊断出潜在的性能瓶颈,这些瓶颈将影响您的应用程序扩展.
在每个测试周期继续增量增加负载,直到资源达到设定的阀值.这些阀值包括吞吐量,响应时间和资源利用.例如CPU的阀值是75,那您可以继续增加负载直到CPU使用率达到80.
在迭代测试结束后,可以生成分析报告以便您观察应用程序在不同负载情况下的行为.
在整个测试过程中如果您继续增加负载,最终将可能导致您的程序出错.如果您开始接收到HTTP 500(服务器忙)的错误,则表明您的服务器的队列已满并且开始拒绝请求.在ACT压力工具中将返回代码为503的错误.
其它的一些错误可能是由于内存的消耗达到machine.config配置的阀值,或者是进程的死锁超出machine.config中属性指定的持续时间.
通过分析计数器的数据,您可以识别应用程序的瓶颈.然后您要进行研究来修改或者优化您的应用程序,并且再进行一轮测试.
测试环境
服务器:2路CPU 3.0G1G 内存Raid 51G网卡
客户端:4路CPU 3.0G3G内存
交换机:百兆EAS结果本图表中的数据也是通过针对每次测试运行逐渐增大同时连接数(在线用户),并经多次运行测试而得到的.在图表横轴上绘制在线用户数,在竖轴上绘制总请求次数.
659721
1170501
1694477
2003051
2019592 随着用户数的增加,总请求数也随着增加,当用户数加到一定数值时总请求数停止增加,并有下降的趋势,从中我们可以了解到系统处理最大的请求数是400个用户并发的情况.
CPU资源使用走势(单位%)
本图表中的数据也是通过针对每次测试运行逐渐增大同时连接数(在线用户),并经多次运行测试而得到的.在图表横轴上绘制在线用户数,在竖轴上绘制CPU的资源使用百分比.
95 随着用户的增加,CPU的使用率也随着增加,可以从中得出:当当前并发数为200的时候CPU的资源被充分的使用.
本图表中的数据也是通过针对每次测试运行逐渐增大同时连接数(在线用户),并经多次运行测试而得到的.在图表横轴上绘制在线用户数,在竖轴上绘制响应时间.
151.05
287.24
597.17 随着用户的增加,响应时间也随之增加,可以看出在并发数为500百时响应时间也未超出一秒.
本图表中的数据也是通过针对每次测试运行逐渐增大同时连接数(在线用户),并经多次运行测试而得到的.在图表横轴上绘制在线用户数,在竖轴上绘制可用内存.
157.23
172.02
199.68 可以看出当并发用户从200变成300时系统的可用内存基本保持一样,当并发用户升到400时可用内存反而增大,和CPU使用率的走势图来看并发用户达到400时CPU使用率已接近100,服务器拒绝了请求,这时候已表明CPU资源出现瓶颈.
平均每秒接收和发送的总字节数走势(单位M)
本图表中的数据也是通过针对每次测试运行逐渐增大同时连接数(在线用户),并经多次运行测试而得到的.在图表横轴上绘制在线用户数,在竖轴上绘制总字节数.
2.86 随着用户数的增大,数据的流量就越大,带宽的要求更高.本图表中的数据也是通过针对每次测试运行逐渐增大同时连接数(在线用户),并经多次运行测试而得到的.在图表横轴上绘制在线用户数,在竖轴上绘制未完成的请求数量.
0.04 随着用户的增加,磁盘中未完成的请求数有一个从低到高,再从高到低的过程,估计这个现象也是由于CPU资源的瓶颈造成的.
输出
测试的结论包括以下几个方面:更新测试计划在不同的负载条件下应用程序的行为最大的操作能力潜在的瓶颈对瓶颈修改的建议参考文档

doc文档的标签：基础测试了解性能

更多推荐标签：栀子花劳动法学作业大客户体育运动概论市场调查蓝牙小学生学籍表英文数控机床中学生手机环境法规俄汉词典床头灯学习乘法原理买卖楼花世界港口资料政策研究计划修铁路大合唱歌曲人工智能优化花店的策划书开体报告节日活动方案广告媒体策略徐家龙苏东坡词下载干部作风船舶物流论文公关方法广告活动策划自查表格下载走出十五年