情绪管理LR压力测试结果分析探讨.docx
- 文档编号:30646275
- 上传时间:2023-08-18
- 格式:DOCX
- 页数:12
- 大小:42.24KB
情绪管理LR压力测试结果分析探讨.docx
《情绪管理LR压力测试结果分析探讨.docx》由会员分享,可在线阅读,更多相关《情绪管理LR压力测试结果分析探讨.docx(12页珍藏版)》请在冰豆网上搜索。
情绪管理LR压力测试结果分析探讨
(情绪管理)LR压力测试结果分析探讨
LoadRunner压力测试结果分析探讨
分析原则:
1.具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点)
2.查找瓶颈时按以下顺序,由易到难。
服务器硬件瓶颈网络瓶颈(对局域网,能够不考虑)服务器操作系统瓶颈(参数配置)中间件瓶颈(参数配置,数据库,web服务器等)应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)
分析的信息来源:
1.根据场景运行过程中的错误提示信息
2.根据测试结果收集到的监控指标数据
壹.错误提示分析
分析实例:
1.Error:
Failedtoconnecttoserver“172.17.7.230″:
[10060]Connection
Error:
timedoutError:
Server“172.17.7.230″hasshutdowntheconnectionprematurely
分析:
A、应用服务死掉。
(小用户时:
程序上的问题。
程序上处理数据库的问题,实际测试中多半是服务器链接的配置问题)
B、应用服务没有死
(应用服务参数设置问题)
对应的Apache和tomcat的最大链接数需要修改,如果连接时收到connectionrefused消息,说明应提高相应的服务器最大连接的设置,增加幅度要根据实际情况和服务器硬件的情况来定,建议每次增加25%!
C、数据库的连接
(数据库启动的最大连接数(跟硬件的内存有关))
D、我们的应用程序spring控制的最大链接数太低
2.Error:
Pagedownloadtimeout(120seconds)hasexpired
分析:
A、应用服务参数设置太大导致服务器的瓶颈
B、页面中图片太多
C、于程序处理表的时候检查字段太大多
D、实际测试时有些资源需要请求外网,而我们的测试环境是局域网环境
3.Error“http:
//172.17.7.230/Home.do....”
分析:
A、脚本设计错误,造成页面异常。
服务器有响应!
B、且发数过大,造成服务器响应延迟。
4.Errorpage“text=xxxxx”
分析:
A、脚本设计问题,例如,前壹脚本修改了某些内容,造成后面的脚本访问异常。
B、不确定因素,有时候回放正常的脚本,壹放到场景中就出现这样的错误。
只能反复修改脚本!
二.监控指标数据分析
1.Vusers数
Loadrunner系统设置的虚拟用户数目。
Vuser去实际调用事先制作的脚本文件中的应用。
每个Vuser产生响应的操作,所有的操作对服务器形成且发。
颜色比例度量图最小值图平均值图最大值图中间值图SD
1Run0.021.25444121.276
于实际测试中,Vusers能够根据实际情况的需要,于测试过程中增加或者减少。
2.最大且发用户数:
颜色比例度量最小值平均值最大值SD
100ApacheCPU使用情况(Apache):
172.17.7.2100.7770.8520.930.043
0.01已发送KB/秒(Apache):
172.17.7.21061430.3712689.333327.924
0.1点击次数/秒(Apache):
172.17.7.2100.333114.352533.66740.201
应用系统于当前环境下能承受的最大且发用户数。
于方案运行中,如果出现了大批用户的业务操作失败,或出现了服务器shutdown的情况,则说明于当前环境下,系统承受不了当前且发用户的负载压力,那么最大且发用户数就是前壹个没有出现这种现象的且发用户数。
从上图能够见出:
于测试运行到4个小时左右的时候,apache的点击数/秒开始迅速增加!
3.业务操作响应时间:
使用“事务性能摘要”图,能够确定于方案执行期间响应时间过长的事务。
颜色比例度量
1最小值
1平均值
1最大值
分析事务的响应情况,要每次详细分析,目前仍只能观察到响应时间过长的事务!
4.每秒点击数
负载测试期间每秒内Vuser于Web服务器上点击的次数。
可根据点击次数来估算Vuser生成的负载数。
颜色比例度量图最小值平均值图最大值图中间值图SD
1点击次数69.908105.736130.244103.66612.186
从图中不难见出,于4小时的时候,点技数明显增高。
和apache的每秒点击数增大的时间相吻合!
5.吞吐量
负载测试期间Web服务器上的吞吐量(字节)。
吞吐量表示于任何指定秒内Vuser从服务器接收到的数据量。
此图可估计Vuser生成的负载量(服务器吞吐量)。
颜色比例度量图最小值平均值图最大值图中间值图SD
1Throughput1257502.7951375591.3721525865.0471372743.69149130.473
同样,从图中能够见出,于4个小时的时候,web服务器的吞吐量开始增高。
于图中仍能够见到吞吐量的走势图,从开始到进行到4个小时反弹之前呈降低的趋势,这是因为系统于初期调用的资源均是直接来之服务器,运行壹段时间后系统的部分资源来自缓存。
6.下载组件大小
每个页面的组件大小,且包括组件的标头的大小!
页面组件大小的分析表格比较复杂,实际分析中能够通过loadrunner的方案分析工具来分析。
页面组件大小分析主要是找到页面中比较庞大的组件,如果其影响到了页面的下载速度,则要想办法将其改小!
7.Apache资源
显示APACHEweb服务器上的资源摘要。
前面已经提到过以且发点击数为主。
颜色比例度量最小值平均值最大值SD
100ApacheCPU使用情况(Apache):
172.17.7.2100.7770.8520.930.043
0.01已发送KB/秒(Apache):
172.17.7.21061430.3712689.333327.924
0.1点击次数/秒(Apache):
172.17.7.2100.333114.352533.66740.201
三.服务器资源监控指标:
(目前通过top监察)
内存:
Linux资源监控中指标内存页交换速率(Pagingrate),如果该值偶尔走高,表明当时有线程竞争内存。
如果持续很高,则内存可能是瓶颈。
也可能是内存访问命中率低。
实际测试中,当且发点击数出现突然剧增前后,内存的PR值则居高25不下。
说明目前测试的系统中内存存于瓶颈!
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(highpageoutrate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率;
内存不够出错(outofmemoryerrors)
处理器:
Linux资源监控中指标CPU占用率持续超过80%(对该值的要求,根据具体应用和机器配置而要求不同,有资料表明95%),表明瓶颈是CPU。
实际测试中,当且发点技数出现突然增加前后,cpu的占用率持续保持于86%之上!
说明,目前系统用应用的cpu也是测试的瓶颈!
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slowresponsetime)
CPU空闲时间为零(zeropercentidleCPU)
过高的用户占用CPU时间(highpercentuserCPU)
过高的系统占用CPU时间(highpercentsystemCPU)
长时间的有很长的运行进程队列(largerunqueuesizesustainedovertime)
四.数据库服务器:
数据库服务器目前测试观察,当web服务器点击率增大时,观察mysql数据库的最大连接数,仍未超过系统设置的最大连接数。
所以,暂时未发现数据库的瓶颈!
五.结论
之上方案分析中的数据、图标均来自同壹次测试。
是于平时测试中挑出的壹次现象比较明显,比较利于观察的作为分析案例。
根据之上综合分析,当前测试环境下,当应用系统产生最大533.667的且发压力。
平均负载压力114.352。
根据分析,用户于4个小时的时候,且发数迅速增加前后的值于400左右!
分析结果跟实际测试的硬件环境以及测试脚本有壹定关系。
同时,测试服务器的硬件配置和实际服务器的配置仍有壹定的差距!
转壹份于51testing上的讨论——如何测试壹个门户网站是否能够支持10万用户同时于线?
Postedon2006-11-1601:
21Jackei阅读(6074)评论(5)编辑收藏网摘所属分类:
04.软件性能测试
这个帖子的内容比较典型,大家有兴趣能够也思考壹下。
先是楼主提出问题:
最近X公司壹个项目,是个门户网站,需要做性能测试,根据项目特点定出了主要测试项和测试方案
壹种是测试几个常用页面能接受的最大且发数(用户名参数化,设置集合点策略)
壹种是测试服务器长时间压力下,用户能否正常操作(用户名参数化,迭代运行脚本)
仍有壹种则需要测试服务器能否接受10万用户同时于线操作,但使用的Loadrunner的license只能支持1万用户,请问这时该如何制定该方案?
后面跟着大家的回复:
网友xingcyx的回复:
1、找10台电脑也没用,license仍然只支持10000个。
2、找HP支持。
当然,前提是你有足够的钱。
3、测到10000用户且发。
我认为,通常情况下10000用户且发,支持100000用户于线,没有问题的。
网友jackloo的回复:
总的来说这壹类的性能指标对大多数软件来说没什么实际意义,更多的是对硬件的要求。
如果是用IIS做应用服务器的话,单台可承受的最大且发数不可能达到10万级,那就必须要使用集群,通过多台机器做负载均衡来实现;
如果是用websphere之类的应用服务器的话,单台可承受的最大且发数能够达到10万级,但为性能考虑仍是必须要使用集群,通过多台机器做负载均衡来实现;
那么,你只要集群的服务器足够多,10万且发数当然能够达到了。
通常有1个简单的计算方式,1个连接产生1个session,每个session于服务器上有个内存空间大小的设置,于NT上是3M,那么10万且发就需要300G内存,当然实际使用中考虑其他程序也占用内存,所以准备的内存数量要求比这个仍要多壹些。
仍有10万个用户同时于线,跟10万个且发数是完全不同的2个概念。
这个楼上已经说了。
但如何做这个转换将10万个同时于线用户转换成多少个且发数呢?
这就必须要有大量的历史日志信息来支撑了。
系统日志需要有同时于线用户数量的日志信息,仍需要有用户操作次数的日志信息,这2个数据的比例就是你同时于线用户转换到且发数的比例。
另外根据经验统计,对于1个JAVA开发的WEB系统(别的我没统计过,给不出数据),壹般1台双CPU、2G内存的服务器上可支持的最大且发数不超过500个(这个状态下大部分操作均是超时报错而且服务器很容易宕机,其实没什么实际意义),可正常使用(单步非大数据量操作等待时间不超过20秒)的最大且发数不超过300个。
假设你的10万同时于线用户转换的且发数是9000个,那么你最少需要这样的机器18台,建议不少于30台。
当然,你要是买个大型服务器,里面装有200个CPU、256G的内存,千兆光纤带宽,就算是10万个且发用户,那速度,也绝对是嗖嗖的。
楼主的回复:
谢谢jackloo!
再请问如果我想测试10000个用户同时于线做常用操作的话(每俩秒加壹个用户,壹直加到10000),对服务器的要求有多高?
网友jackloo的回复:
套用1句经典台词“高,实于是高”
呵呵。
另外暴寒1下,你的设置光全部进入运行状态就需要接近6个小时。
具体的你能够拿1个系统来压壹下见见,可能会出现以下情况:
1。
服务器宕机;
2。
客户端宕机;
3。
从某个时间开始服务器拒绝请求,客户端上显示的全是错误;
4。
勉强测试完成,但网络堵塞或测试结果显示时间非常长。
假设客户端和服务器之间百兆带宽,百兆/10000=10K,那每个用户只能得到10K,这个速度接近1个64K的MODEM上网的速度;
另外之上分析全均没考虑系统的后台,比如数据库、中间件等。
我从没遇到你说的这样的性能需求过,也只好凭感觉随便掰掰:
1。
服务器方面:
上面说的那样的PCSERVER需要50台;
2。
网络方面:
按每个用户50K,那至少5根百兆带宽独享,估计仅仅网络延迟就大概是秒壹级的;
3。
如果有数据库,至少是ORACLE,最好是SYSBASE,SQLSERVER是肯定顶不住的。
数据库服务器至少需要10台4CPU、16G内存的机器;
4。
如果有CORBA,那至少再准备10台4CPU、16G内存的机器;
再加上负载均衡、防火墙、路由器和各种软件等,总之没个1000万的资金投入,肯定搞不定。
网友mybasswood的回复:
如果是10万用户的话要见做些什么哈.
比如对于voip来说,假设有10万用户的话,服务器规定每个client至少要于3600秒内到服务器成功报到壹次,否则就被服务器cancel掉.
client是每隔60秒注册壹次.
所以就要推算于3600秒内,每壹个client至少成功报到壹次是最少的标准.要10万用户于3600秒内被服务器吃掉才能够---这是最低要求.
最高要求是:
于60秒内所有的10万用户去注册,如果服务器于60秒能够均吃掉的话,每秒种的平均且发差不多是3334.
最低要求是:
于3600秒内所有的10用户去注册,如果服务器于3600秒内均能够吃掉的话,每秒钟的平均且发用户差不多是60个.仍有壹过问题是客户端要于3600秒内发送至少60次,至少有壹次成功.再加上这些用户分布于全球各地的话,这样数值应该仍会有变化的.
下面是偶的见法:
给楼主壹个建议吧。
你于X公司中的测试环境是壹定的,你需要做得是当下这个环境中确认壹下系统于当前环境下的实际处理能力。
如果仍有资源,再做壹下可伸缩性的测试。
然后对测试结果进行分析,对系统的处理能力和可伸缩性做壹个描述。
当然,要于方案中说明你的测试环境。
另外壹位网友robust的留言:
你的意思是否想用10000个用户测试结果来推测壹下10万个用户?
仍是如有些老兄说的,测试壹下什么伸缩性测试.然后也来个方案,无非也是想用1万个来推测10万个的情况?
(评注:
那样的话要你做什么性能测试,只要计算壹下就能够得性能结果了.)
仍是如有些老兄说的,这壹类的性能指标对大多数软件来说没什么实际意义,更多的是对硬件的要求?
(评注:
那样的话要你做什么性能测试,做什么性能调优,只要计算壹下,添加硬件就能够了.)
实际上,"实践是检验真理的唯壹标准!
"这句话才是硬道理.只有真实地测试过才知道.任何推测只是推测,且不能反映真实的情况.
至于性能测试工具,LR只是普及率高(市场占有率高),且不是于性能指标上有优势.世界上比它厉害的工具有不少,举个例子siprent通信X公司的avalanche2500,大型计算机实验室配备的性能测试工具.支持录制/回放,测试结果分析等.它能够模拟从数据层到应用层的协议,(当然也包含http-web),单个支持100万且发连接.拿它也能够测试100万级的且发性能.
又是偶的回复:
楼上的提到的见解不错,不过对性能测试的理解有些偏差。
先抛开性能测试工具不谈,其实这个问题是讨论到壹个性能测试到底该怎么做。
简单举个例子,如果你想知道壹种新的疫苗对人的作用,是不是要把所有的地球人全部找来每个人打壹针试试呢?
当然不是,只能是通过试验和抽样,然后通过统计学的方法来计算出壹个模型,通过样本的表现来估算总体的特征。
这就是统计学研究的领域,。
不过请注意,统计学所包含的内容且不是像楼上的老兄所说的壹样:
只要计算壹下就能够得性能结果了。
性能测试也同样如此。
楼主提到的性能需求应该是系统上线以后可能要面临的压力,先不讨论这个需求是否准确和有效,我们先假定它是有效的。
那么,既然要验证的是系统于上线以后是否有能力应对10万用户同时于线的情况,那么自然要用生产环境来测试。
如果有,那么OK,能够作这个测试。
至于工具,其实能够由开发人员帮忙写壹些简单的脚本负责加压,再通过其他第三方工具收集测试数据就是了。
可是如果没有生产环境,只有壹台双CPU,3G内存的2850服务器,怎么办?
这就好像上面提到的例子。
可行的方法是于这台服务器上使用不同级别的负载来进行测试,且根据测试数据获得系统于这种环境下的最佳负载和最大负载,且根据测试数据对负载和资源消耗的情况进行估算,找到它们之间的关系。
壹般来说,大型的门户网站不会只用壹台超级超级的服务器来承担所有的负载,因为采用负载均衡和集群技术能够更好的解决这个问题,壹定是多台服务器分布于不同的地方,内容通过内容分发网络同步到各台服务器上。
用户于访问时,其实是被应用层或者前端设备路由到壹个合适的服务器去的。
所以于测试时,对于可伸缩性的测试是必需的,壹定要了解到cluster数量增加时,系统的响应能力是否能够线性的增加,也就是说是否能够承受更大的压力,为更多的用户提供服务。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 情绪 管理 LR 压力 测试 结果 分析 探讨