LoadRunner压力测试结果分析探讨6647.docx

《LoadRunner压力测试结果分析探讨6647.docx》由会员分享，可在线阅读，更多相关《LoadRunner压力测试结果分析探讨6647.docx（18页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、LoadRunner压力测试结果分析探讨分析原则：1. 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）2. 查找瓶瓶颈时按按以下顺顺序，由由易到难难。服务器器硬件瓶瓶颈 网络瓶瓶颈（对对局域网网，可以以不考虑虑） 服务器器操作系系统瓶颈颈（参数数配置） 中间间件瓶颈颈（参数数配置，数据库，web服务器等） 应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）分析的的信息来来源：1. 根据场场景运行行过程中中的错误误提示信信息2. 根据测测试结果果收集到到的监控控指标数数据一错误提提示分析析分析实例例：1EErroor: Faiiledd too coonneect

2、 to serrverr “1172.17.7.2230: 100060 CoonneectiionErrror: tiimedd ouut EErroor: Serrverr “1172.17.7.2230 haas sshutt doown thee coonneectiion preemattureely分析：A、应应用服务务死掉。（小用用户时：程序上上的问题题。程序序上处理理数据库库的问题题，实际际测试中中多半是是服务器器链接的的配置问问题）B、应应用服务务没有死死（应用用服务参参数设置置问题）对应的的Apaachee和toomcaat的最最大链接接数需要要修改，如如果连接接时收到到c

3、onnnecctioon rrefuusedd消息，说说明应提提高相应应的服务务器最大大连接的的设置，增增加幅度度要根据据实际情情况和服服务器硬硬件的情情况来定定，建议议每次增增加255%！C、数数据库的的连接(数据据库启动动的最大大连接数数（跟硬硬件的内内存有关关）)D、我我们的应应用程序序sprringg控制的的最大链链接数太太低2. Errror: Paage dowwnlooad timmeouut (1200 seeconnds) haas eexpiiredd分析：A、应应用服务务参数设设置太大大导致服服务器的的瓶颈B、页页面中图图片太多多C、在在程序处处理表的的时候检检查字段段太

4、大多多D、实实际测试试时有些些资源需需要请求求外网，而而我们的的测试环环境是局局域网环环境3. Errror “htttp:/1172.17.7.2230/Homme.ddo.”分析：A、脚脚本设计计错误，造造成页面面异常。服服务器有有响应！B、并并发数过过大，造造成服务务器响应应延迟。4. Errror pagge “ttextt=xxxxxxx”分析：A、脚脚本设计计问题，例例如，前前一脚本本修改了了某些内内容，造造成后面面的脚本本访问异异常。B、不不确定因因素，有有时候回回放正常常的脚本本，一放放到场景景中就出出现这样样的错误误。只能能反复修修改脚本本！二监控控指标数数据分析析1Vuss

5、erss数Loaadruunneer 系系统设置置的虚拟拟用户数数目。VVuseer去实实际调用用事先制制作的脚脚本文件件中的应应用。每个VVuseer产生生响应的的操作，所所有的操操作对服服务器形形成并发发。颜色 比例 度量 图最小小值 图图平均值值 图最最大值 图中间间值 图图SD1 RRun 0.00 211.255 444 411 211.2776在实际际测试中中，Vuuserrs可以以根据实实际情况况的需要要，在测测试过程程中增加加或者减减少。2最大并并发用户户数：颜色 比例 度量 最小值值 平均均值 最最大值 SD1000 Appachhe CCPU 使用情情况(AApacche)

6、:1772.117.77.2110 00.7777 00.8552 00.933 0.04330.001 已已发送 KB/秒(AApacche):1772.117.77.2110 66 14430.3711 26689.3333 3227.99240.11 点击击次数/秒(AApacche):1772.117.77.2110 00.3333 1114.3522 5333.6667 40.2011应用系系统在当当前环境境下能承承受的最最大并发发用户数数。在方案案运行中中，如果果出现了了大批用用户的业业务操作作失败，或或出现了了服务器器shuutdoown的的情况，则则说明在在当前环环境下，系系统

7、承受受不了当当前并发发用户的的负载压压力，那那么最大大并发用用户数就就是前一一个没有有出现这这种现象象的并发发用户数数。从上图图可以看看出：在在测试运运行到44个小时时左右的的时候，aapacche的的点击数数/秒开开始迅速速增加！3业务务操作响响应时间间：使用“事事务性能能摘要”图图，可以以确定在在方案执执行期间间响应时时间过长长的事务务。颜色 比例 度量1 最最小值1 平平均值1 最最大值分析事事务的响响应情况况，要每每次详细细分析，目目前还只只能观察察到响应应时间过过长的事事务！4每秒点点击数负载测测试期间间每秒内内 Vuuserr 在 Webb 服务务器上点点击的次次数。可可根据点点击

8、次数数来估算算 Vuuserr 生成成的负载载数。颜色 比例 度量 图最小小值 平平均值 图最大大值 图图中间值值 图SSD1 点点击次数数 699.9008 1105.7366 1330.2244 1033.6666 112.1186从图中中不难看看出，在在4小时时的时候候，点技技数明显显增高。和和apaachee的每秒秒点击数数增大的的时间相相吻合！5吞吐量量负载测测试期间间 Weeb 服服务器上上的吞吐吐量(字字节)。吞吞吐量表表示在任任何指定定秒内 Vusser 从服务务器接收收到的数数据量。此此图可估估计 VVuseer 生生成的负负载量(服务器器吞吐量量)。颜色 比例 度量 图最小

9、小值 平平均值 图最大大值 图图中间值值 图SSD1 TThrooughhputt 122575502.7955 133755591.3722 155258865.0477 133727743.6911 4991300.4773同样，从从图中可可以看出出，在44个小时时的时候候，weeb服务务器的吞吞吐量开开始增高高。在图图中还可可以看到到吞吐量量的走势势图，从从开始到到进行到到4个小小时反弹弹之前呈呈降低的的趋势，这这是因为为系统在在初期调调用的资资源都是是直接来来之服务务器，运运行一段段时间后后系统的的部分资资源来自自缓存。6下载组组件大小小每个页页面的组组件大小小，且包包括组件件的标头头

10、的大小小！页面组组件大小小的分析析表格比比较复杂杂，实际际分析中中可以通通过looadrrunnner的的报告分分析工具具来分析析。页面面组件大大小分析析主要是是找到页页面中比比较庞大大的组件件，如果果其影响响到了页页面的下下载速度度，则要要想办法法将其改改小！7Appachhe资源源显示AAPACCHE webb服务器器上的资资源摘要要。前面面已经提提到过以以并发点点击数为为主。颜色 比例 度量 最小值值 平均均值 最最大值 SD1000 Appachhe CCPU 使用情情况(AApacche):1772.117.77.2110 00.7777 00.8552 00.933 0.04330

11、.001 已已发送 KB/秒(AApacche):1772.117.77.2110 66 14430.3711 26689.3333 3227.99240.11 点击击次数/秒(AApacche):1772.117.77.2110 00.3333 1114.3522 5333.6667 40.2011三服务器器资源监监控指标标：（目前前通过ttop监监察）内存：Linnux资资源监控控中指标标内存页页交换速速率（PPagiing ratte），如如果该值值偶尔走走高，表表明当时时有线程程竞争内内存。如如果持续续很高，则则内存可可能是瓶瓶颈。也也可能是是内存访访问命中中率低。实际测测试中，当当并

12、发点点击数出出现突然然剧增前前后，内内存的PPR 值值则居高高25不不下。说说明目前前测试的的系统中中内存存存在瓶颈颈！内存资资源成为为系统性性能的瓶瓶颈的征征兆:很高的的换页率率(hiigh paggeouut rratee);进程进进入不活活动状态态;交换区区所有磁磁盘的活活动次数数可高;可高的的全局系系统CPPU利用用率;内存不不够出错错(ouut oof mmemoory errrorss)处理器：Linnux资资源监控控中指标标CPUU占用率率持续超超过800%（对对该值的的要求，根根据具体体应用和和机器配配置而要要求不同同，有资资料表明明95），表表明瓶颈颈是CPPU。实际测测试中

13、，当当并发点点技数出出现突然然增加前前后，ccpu的的占用率率持续保保持在886以以上！说明，目目前系统统用应用用的cppu也是是测试的的瓶颈！CPUU资源成成为系统统性能的的瓶颈的的征兆:很慢的的响应时时间(ssloww reespoonsee tiime)CPUU空闲时时间为零零(zeero perrcennt iidlee CPPU)过高的的用户占占用CPPU时间间(hiigh perrcennt uuserr CPPU)过高的的系统占占用CPPU时间间(hiigh perrcennt ssysttem CPUU)长时间间的有很很长的运运行进程程队列(larrge runn quueue

14、e siize susstaiinedd ovver timme)四数据据库服务务器：数据库库服务器器目前测测试观察察，当wweb服服务器点点击率增增大时，观观察myysqll数据库库的最大大连接数数，仍未未超过系系统设置置的最大大连接数数。所以以，暂时时未发现现数据库库的瓶颈颈！五结论论以上报报告分析析中的数数据、图图标均来来自同一一次测试试。是在在平时测测试中挑挑出的一一次现象象比较明明显，比比较利于于观察的的作为分分析案例例。根据以以上综合合分析，当当前测试试环境下下，当应应用系统统产生最最大5333.6667的的并发压压力。平平均负载载压力1114.3522。根据据分析，用用户在44个

15、小时时的时候候，并发发数迅速速增加前前后的值值在4000左右右！分析析结果跟跟实际测测试的硬硬件环境境以及测测试脚本本有一定定关系。同同时，测测试服务务器的硬硬件配置置和实际际服务器器的配置置还有一一定的差差距！转一份在 51ttesttingg 上的的讨论如何何测试一一个门户户网站是是否可以以支持110万用用户同时时在线？Posteed oon 220066-111-166 011:211 Jaackeei 阅阅读(660744) 评评论(55) 编辑收藏藏网摘 所所属分类类: 004.软软件性能能测试这个帖子的的内容比比较典型型，大家家有兴趣趣可以也也思考一一下。先是楼主提提出问题题：最近

16、公司一一个项目目,是个个门户网网站,需需要做性性能测试试,根据据项目特特点定出出了主要要测试项项和测试试方案一一种是测测试几个个常用页页面能接接受的最最大并发发数(用用户名参参数化,设置集集合点策策略)一一种是测测试服务务器长时时间压力力下,用用户能否否正常操操作(用用户名参参数化,迭代运运行脚本本)还有有一种则则需要测测试服务务器能否否接受110万用用户同时时在线操操作,但但使用的的Loaadruunneer的lliceensee只能支支持1万万用户,请问这这时该如如何制定定该方案案?后面跟着大大家的回回复：网友 xxinggcyxx 的的回复：1、找100台电脑脑也没用用，liicenns

17、e仍仍然只支支持1000000个。22、找HHP支持持。当然然，前提提是你有有足够的的钱。33、测到到100000用用户并发发。我认认为，通通常情况况下1000000用户并并发，支支持10000000用户户在线，没没有问题题的。网友 jjackklooo 的回回复：总的来说这这一类的的性能指指标对大大多数软软件来说说没什么么实际意意义，更更多的是是对硬件件的要求求。如果果是用IIIS做做应用服服务器的的话，单单台可承承受的最最大并发发数不可可能达到到10万万级，那那就必须须要使用用集群，通通过多台台机器做做负载均均衡来实实现；如如果是用用webbsphheree之类的的应用服服务器的的话，单单

18、台可承承受的最最大并发发数可以以达到110万级级，但为为性能考考虑还是是必须要要使用集集群，通通过多台台机器做做负载均均衡来实实现；那那么，你你只要集集群的服服务器足足够多，110万并并发数当当然可以以达到了了。通常常有1个个简单的的计算方方式，11个连接接产生11个seessiion，每每个seessiion在在服务器器上有个个内存空空间大小小的设置置，在NNT上是是3M，那那么100万并发发就需要要3000G内存存，当然然实际使使用中考考虑其他他程序也也占用内内存，所所以准备备的内存存数量要要求比这这个还要要多一些些。还有有10万万个用户户同时在在线，跟跟10万万个并发发数是完完全不同同的

19、2个个概念。这这个楼上上已经说说了。但但如何做做这个转转换将110万个个同时在在线用户户转换成成多少个个并发数数呢？这这就必须须要有大大量的历历史日志志信息来来支撑了了。系统统日志需需要有同同时在线线用户数数量的日日志信息息，还需需要有用用户操作作次数的的日志信信息，这这2个数数据的比比例就是是你同时时在线用用户转换换到并发发数的比比例。另另外根据据经验统统计，对对于1个个JAVVA开发发的WEEB系统统（别的的我没统统计过，给给不出数数据），一一般1台台双CPPU、22G内存存的服务务器上可可支持的的最大并并发数不不超过5500个个（这个个状态下下大部分分操作都都是超时时报错而而且服务务器很

20、容容易宕机机，其实实没什么么实际意意义），可可正常使使用（单单步非大大数据量量操作等等待时间间不超过过20秒秒）的最最大并发发数不超超过3000个。假设你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不少于30台。当然，你要是买个大型服务器，里面装有200个CPU、256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。楼主的回回复：谢谢jaccklooo!再请问问如果我我想测试试100000个个用户同同时在线线做常用用操作的的话(每每两秒加加一个用用户,一一直加到到100000),对服服务器的的要求有有多高?网友 jaacklloo

21、的回复复：套用1句经经典台词词“高，实实在是高高”呵呵呵。另外外暴寒11下，你你的设置置光全部部进入运运行状态态就需要要接近66个小时时。具体体的你可可以拿11个系统统来压一一下看看看，可能能会出现现以下情情况：11。服务务器宕机机；2。客客户端宕宕机；33。从某某个时间间开始服服务器拒拒绝请求求，客户户端上显显示的全全是错误误；4。勉勉强测试试完成，但但网络堵堵塞或测测试结果果显示时时间非常常长。假假设客户户端和服服务器之之间百兆兆带宽，百百兆/1100000=110K，那那每个用用户只能能得到110K，这这个速度度接近11个644K的MMODEEM上网网的速度度；另外外以上分分析全都都没考

22、虑虑系统的的后台，比比如数据据库、中中间件等等。我从从没遇到到你说的的这样的的性能需需求过，也也只好凭凭感觉随随便掰掰掰：1。服服务器方方面：上上面说的的那样的的PCSERRVERR需要550台；2。网网络方面面：按每每个用户户50KK，那至至少5根根百兆带带宽独享享，估计计仅仅网网络延迟迟就大概概是秒一一级的；3。如如果有数数据库，至至少是OORACCLE，最最好是SSYSBBASEE，SQQLSSERVVER是是肯定顶顶不住的的。数据据库服务务器至少少需要110台44CPUU、166G内存存的机器器；4。如如果有CCORBBA，那那至少再再准备110台44CPUU、166G内存存的机器器；

23、再加加上负载载均衡、防防火墙、路路由器和和各种软软件等，总总之没个个10000万的的资金投投入，肯肯定搞不不定。网友 myybassswoood 的回复复：如果是100万用户户的话要要看做些些什么哈哈.比如如对于vvoipp来说,假设有有10万万用户的的话,服服务器规规定每个个cliientt至少要要在36600秒秒内到服服务器成成功报到到一次,否则就就被服务务器caanceel掉.cliientt是每隔隔60秒秒注册一一次.所所以就要要推算在在36000秒内内,每一一个clliennt至少少成功报报到一次次是最少少的标准准.要110万用用户在336000秒内被被服务器器吃掉才才可以-这这是最

24、低低要求.最高要要求是:在660秒内内所有的的10万万用户去去注册,如果服服务器在在60秒秒可以都都吃掉的的话,每每秒种的的平均并并发差不不多是333344.最低低要求是是:在336000秒内所所有的110用户户去注册册,如果果服务器器在36600秒秒内都可可以吃掉掉的话,每秒钟钟的平均均并发用用户差不不多是660个.还有一一过问题题是客户户端要在在36000秒内内发送至至少600次,至至少有一一次成功功.再加加上这些些用户分分布在全全球各地地的话,这样数数值应该该还会有有变化的的.下面是偶的的看法：给楼主一个个建议吧吧。你在在公司中中的测试试环境是是一定的的，你需需要做得得是现在在这个环环境

25、中确确认一下下系统在在当前环环境下的的实际处处理能力力。如果果还有资资源，再再做一下下可伸缩缩性的测测试。然然后对测测试结果果进行分分析，对对系统的的处理能能力和可可伸缩性性做一个个描述。当然，要在报告中说明你的测试环境。另外一位网网友roobusst 的的留言：你的意思是是否想用用100000个个用户测测试结果果来推测测一下110万个个用户?还是如如有些老老兄说的的,测试试一下什什么伸缩缩性测试试.然后后也来个个报告,无非也也是想用用1万个个来推测测10万万个的情情况?(评注:那样的的话要你你做什么么性能测测试,只只要计算算一下就就可以得得性能结结果了.)还是是如有些些老兄说说的,这这一类的

26、的性能指指标对大大多数软软件来说说没什么么实际意意义，更更多的是是对硬件件的要求求?(评评注:那那样的话话要你做做什么性性能测试试,做什什么性能能调优,只要计计算一下下,添加加硬件就就可以了了.)实实际上,实践践是检验验真理的的唯一标标准!这句话话才是硬硬道理.只有真真实地测测试过才才知道.任何推推测只是是推测,并不能能反映真真实的情情况.至至于性能能测试工工具,LLR只是是普及率率高(市市场占有有率高),并不不是在性性能指标标上有优优势.世世界上比比它厉害害的工具具有不少少,举个个例子ssiprrentt通信公公司的aavallancche225000,大型型计算机机实验室室配备的的性能测测

27、试工具具.支持持录制/回放,测试结结果分析析等.它它可以模模拟从数数据层到到应用层层的协议议,(当当然也包包含htttp-webb),单单个支持持1000万并发发连接.拿它也也可以测测试1000万级级的并发发性能.又是偶的回回复：楼上的提到到的见解解不错，不不过对性性能测试试的理解解有些偏偏差。先先抛开性性能测试试工具不不谈，其其实这个个问题是是讨论到到一个性性能测试试到底该该怎么做做。简单单举个例例子，如如果你想想知道一一种新的的疫苗对对人的作作用，是是不是要要把所有有的地球球人全部部找来每每个人打打一针试试试呢？当然不不是，只只能是通通过试验验和抽样样，然后后通过统统计学的的方法来来计算出

28、出一个模模型，通通过样本本的表现现来估算算总体的的特征。这这就是统统计学研研究的领领域，。不不过请注注意，统统计学所所包含的的内容并并不是像像楼上的的老兄所所说的一一样：只只要计算算一下就就可以得得性能结结果了。性能测试也同样如此。楼主提到的性能需求应该是系统上线以后可能要面临的压力，先不讨论这个需求是否准确和有效，我们先假定它是有效的。那么，既然要验证的是系统在上线以后是否有能力应对10万用户同时在线的情况，那么自然要用生产环境来测试。如果有，那么OK，可以作这个测试。至于工具，其实可以由开发人员帮忙写一些简单的脚本负责加压，再通过其他第三方工具收集测试数据就是了。但是如果没有生产环境，只有

29、一台双CPU，3G内存的2850服务器，怎么办？这就好像上面提到的例子。可行的方法是在这台服务器上使用不同级别的负载来进行测试，并根据测试数据获得系统在这种环境下的最佳负载和最大负载，并根据测试数据对负载和资源消耗的情况进行估算，找到它们之间的关系。一般来说，大型的门户网站不会只用一台超级超级的服务器来承担所有的负载，因为采用负载均衡和集群技术可以更好的解决这个问题，一定是多台服务器分布在不同的地方，内容通过内容分发网络同步到各台服务器上。用户在访问时，其实是被应用层或者前端设备路由到一个合适的服务器去的。所以在测试时，对于可伸缩性的测试是必需的，一定要了解到cluster数量增加时，系统的响

30、应能力是否可以线性的增加，也就是说是否可以承受更大的压力，为更多的用户提供服务。最后总结一下，对于性能测试，要作的是确认系统的响应能力，然后看系统是否可以满足性能需求。如果大家有不同的见解，欢迎PK讨论继续偶的的回复：tojaacklloo你你所提到到的对于于硬件资资源和软软件资源源的要求求并不完完全准确确。因为为实际的的资源消消耗要根根据网站站所提供供的业务务类型来来推算。对于大多数门户网站来说，可供访问的大多是静态页面。在用户访问时，系统只是返回一个静态页面给用户，并不需要保持session，而且这种情况下负载主要集中在I/O和网络流量方面这也是为什么大型门户网站都会采用分布式的方式来部署

31、服务器。当然，如果使用了cache，内存的使用会随着服务器运行时间的延长而增加，但是CPU通常不会成为关键资源。这是门户网站同企业应用或者在线游戏的区别。还是偶：to楼主主上面我我也提到到了，你你需要进进一步的的明确你你的测试试需求是是否有效效，合理理。性能能需求需需要根据据网站具具体提供供的业务务类型来来作为依依据进行行衡量。就就如同上上面提到到的，是是只提供供了静态态页面的的访问？还是有有其他的的业务？要区分分清楚注注册用户户、在线线用户和和并发用用户的区区别。另另外，你你最迫切切需要担担心的并并不应该该是LLR的的liicennse问题，而而是被测测的系统统能否支支持的了了几百或或者几千千并发用用户，如如果连这这个都支支持不了了，就更更不用考考虑上万万的并发发访问了了。希望大家有有不同的的看法和和意见都都可以写写下来，大大家一起起讨论，共共同进步步。