ImageVerifierCode 换一换
格式:DOCX , 页数:14 ,大小:23.83KB ,
资源ID:11213912      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/11213912.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(LoadRunner压力测试结果分析探讨.docx)为本站会员(b****7)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

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

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

2、30 : 10060ConnectionError: timed out Error: Server “ 172.17.7.230 has shut down theconn ecti on prematurely分析:A、 应用服务死掉。(小用户时:程序上的问题。程序上处理数据库的问题,实际测试中多半是 服务器链接的配置问题)B、 应用服务没有死(应用服务参数设置问题)对应的 Apache 和 tomcat 的最大链接数需要修改,如果连接时收到 connection refused 消息,说明应提高相应的服务器最大连接的设置,增加幅 度要根据实际情况和服务器硬件的情况来定,建议每次增加 25

3、%!C、数据库的连接( 数据库启动的最大连接数(跟硬件的内存有关) )D我们的应用程序spring控制的最大链接数太低2.Error: Page download timeout (120 seconds) has expired分析:A、 应用服务参数设置太大导致服务器的瓶颈B、 页面中图片太多C、 在程序处理表的时候检查字段太大多D实际测试时有些资源需要请求外网,而我们的测试环境是局域网环境3.Error “http:/172.17.7.230/Home.do ”分析:A、 脚本设计错误,造成页面异常。服务器有响应!B、 并发数过大,造成服务器响应延迟。4.Error page “text

4、=xxxxx ”分析:A、 脚本设计问题,例如,前一脚本修改了某些内容,造成后面的脚本访问 异常。B、 不确定因素,有时候回放正常的脚本,一放到场景中就出现这样的错误 只能反复修改脚本!二监控指标数据分析1Vusers 数Loadrunner 系统设置的虚拟用户数目。 Vuser 去实际调用事先制作的脚本 文件中的应用。每个 Vuser 产生响应的操作,所有的操作对服务器形成并发。颜色 比例 度量 图最小值 图平均值 图最大值 图中间值 图 SD1 Run 0.0 21.25 44 41 21.276在实际测试中, Vusers 可以根据实际情况的需要,在测试过程中增加或者 减少。2最大并发用

5、户数:颜色 比例 度量 最小值 平均值 最大值 SD100 Apache CPU使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.0430.01 已发送 KB/ 秒(Apache):172.17.7.210 6 1430.371 2689.333 327.9240.1 点击次数 / 秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201应用系统在当前环境下能承受的最大并发用户数。在方案运行中,如果出现了大批用户的业务操作失败,或出现了服务器 shutdown 的情况,则说明在当前环境下,系统承受不了当前并发

6、用户的负载压 力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数。从上图可以看出:在测试运行到 4个小时左右的时候, apache 的点击数 /秒 开始迅速增加!3 业务操作响应时间:使用 “事务性能摘要 ”图,可以确定在方案执行期间响应时间过长的事务。颜色 比例 度量1 最小值1 平均值1 最大值分析事务的响应情况, 要每次详细分析, 目前还只能观察到响应时间过长的事务!4每秒点击数负载测试期间每秒内 Vuser 在 Web 服务器上点击的次数。 可根据点击次数来估算 Vuser 生成的负 载数。颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图 SD1 点击次数 69.9

7、08 105.736 130.244 103.666 12.186从图中不难看出,在 4 小时的时候,点技数明显增高。和 apache 的每秒点击数增大的时间相吻合!5吞吐量负载测试期间 Web 服务器上的吞吐量 (字节 )。吞吐量表示在任何指定秒内 Vuser 从服务器接收到的 数据量。此图可估计 Vuser 生成的负载量 (服务器吞吐量 )。颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图 SD1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473同样,从图中可以看出,在 4 个小时的时候, w

8、eb 服务器的吞吐量开始增高。在图中还可以看到吞吐 量的走势图,从开始到进行到 4 个小时反弹之前呈降低的趋势,这是因为系统在初期调用的资源都是直接 来之服务器,运行一段时间后系统的部分资源来自缓存。6下载组件大小每个页面的组件大小,且包括组件的标头的大小!页面组件大小的分析表格比较复杂,实际分析中可以通过 loadrunner 的报告分析工具来分析。页面组 件大小分析主要是找到页面中比较庞大的组件,如果其影响到了页面的下载速度,则要想办法将其改小!7 Apache 资源显示 APACHE web 服务器上的资源摘要。前面已经提到过以并发点击数为主。颜色 比例 度量 最小值 平均值 最大值 S

9、D100 Apache CPU 使用情况 (Apache):172.17.7.210 0.777 0.852 0.93 0.0430.01 已发送 KB/ 秒 (Apache):172.17.7.210 6 1430.371 2689.333 327.9240.1 点击次数 /秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201三服务器资源监控指标:(目前通过 top 监察)内存:Linux 资源监控中指标内存页交换速率( Paging rate ),如果该值偶尔走高,表明当时有线程竞争内 存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命

10、中率低。实际测试中,当并发点击数出现突然剧增前后,内存的 PR 值则居高 25 不下。说明目前测试的系统 中内存存在瓶颈!内存资源成为系统性能的瓶颈的征兆 :很高的换页率 (high pageout rate);进程进入不活动状态 ;交换区所有磁盘的活动次数可高 ;可高的全局系统 CPU 利用率 ;内存不够出错 (out of memory errors)处理器:Linux 资源监控中指标 CPU 占用率持续超过 80%(对该值的要求, 根据具体应用和机器配置而要求不 同,有资料表明 95 ),表明瓶颈是 CPU 。实际测试中, 当并发点技数出现突然增加前后, cpu 的占用率持续保持在 86

11、以上!说明,目前系统用应用的 cpu 也是测试的瓶颈!CPU 资源成为系统性能的瓶颈的征兆 :很慢的响应时间 (slow response time)CPU 空闲时间为零 (zero percent idle CPU)过高的用户占用 CPU 时间 (high percent user CPU)过高的系统占用 CPU时间(high percent system CPU)长时间的有很长的运行进程队歹 (large run queue size sustained over time)四数据库服务器:数据库服务器目前测试观察,当 web服务器点击率增大时,观察 mysql数据库的最大连接数,仍未超过

12、系统设置的最大连接数。所以,暂时未发现数据库的瓶颈!五.结论以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑岀的一次现象比较明显,比较利 于观察的作为分析案例。根据以上综合分析,当前测试环境下,当应用系统产生最大 533.667的并发压力。平均负载压力114.352。根据分析,用户在 4个小时的时候,并发数迅速增加前后的值在 400左右!分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时,测试服务器的硬件配置和实际服务器的配置还有一定的差 距!转一份在51testing 上的讨论如何测试一个门户网站是否可以支持 10万用户同时在线?Posted on 2006-11-16 0

13、1:21 Jackei阅读(6074) 评论(5) 编辑 收藏 网摘 所属分类:04.软件性能测试.这个帖子的内容比较典型,大家有兴趣可以也思考一下。先是楼主提岀问题:最近公司一个项目,是个门户网站,需要做性能测试,根据项目特点定出了主要测试项和测一种是测试几个常用页面能接受的最大并发数 (用户名参数化,设置集合点策略)一种是测试服务器长时间压力下,用户能否正常操作(用户名参数化,迭代运行脚本)还有一种则需要测试服务器能否接受 10万用户同时在线操作,但使用的Loadrunner 的Iicense只能支持1万用户,请问这时该如何制定该方案 ?后面跟着大家的回复:网友 xingcyx 的回复:1

14、、 找10台电脑也没用,license仍然只支持10000个。2、 找HP支持。当然,前提是你有足够的钱。3、 测到10000用户并发。我认为,通常情况下 10000用户并发,支持100000 用户 在线,没有问题的。网友jackloo 的回复:总的来说这一类的性能指标对大多数软件来说没什么实际意义,更多的是对硬件的要求。如果是用IIS做应用服务器的话,单台可承受的最大并发数不可能达到 10万级,那就必须要使用集群,通过多台机器做负载均衡来实现;如果是用websphere 之类的应用服务器的话,单台可承受的最大并发数可以达到 10万级,但为性能考虑还是必须要使用集群,通过多台机器做负载均衡来实

15、现;那么,你只要集群的服务器足够多, 10万并发数当然可以达到了。通常有1个简单的计算方式,1个连接产生1个session ,每个session在服务器上有个 内存空间大小的设置,在 NT上是3M,那么10万并发就需要300G内存,当然实际使用 中考虑其他程序也占用内存,所以准备的内存数量要求比这个还要多一些。还有10万个用户同时在线,跟 10万个并发数是完全不同的 2个概念。这个楼上已经说 了。但如何做这个转换将 10万个同时在线用户转换成多少个并发数呢?这就必须要有大量的历史日志信息来支撑了。 系统日志需要有同时在线用户数量的日志信息,还需要有用户操作次数的日志信息,这 2个数据的比例就是

16、你同时在线用户转换到并发数的比例。另外根据经验统计,对于 1个JAVA开发的WEB系统(别的我没统计过,给不出数据) ,一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过 500个(这个状态下大部分操作都是超时报错而且服务器很容易宕机,其实没什么实际意义) ,可正常使用(单步非大数据量操作等待时间不超过 20秒)的最大并发数不超过 300个。假设你的10万同时在线用户转换的并发数是 9000个,那么你最少需要这样的机器 18台,建议不少于 30台。当然,你要是买个大型服务器,里面装有 200个CPU、256G的内存,千兆光纤带宽,就算是10万个并发用户,那速度,也绝对是嗖嗖的。楼主的

17、回复:谢谢 jackloo !再请问如果我想测试 10000 个用户同时在线做常用操作的话 (每两秒加一个用户,一直加到10000),对服务器的要求有多高 ?网友jackloo 的回复:套用1句经典台词 高,实在是高”呵呵。另外暴寒1下,你的设置光全部进入运行状态就需要接近 6个小时。具体的你可以拿1个系统来压一下看看,可能会出现以下情况:1。 服务器宕机;2。 客户端宕机;3。 从某个时间开始服务器拒绝请求,客户端上显示的全是错误;4。 勉强测试完成,但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽,百兆/10000=10K ,那每个用户只能得到 10K,这个速度接近1个6

18、4K的MODEM上网的速度;另外以上分析全都没考虑系统的后台,比如数据库、中间件等。我从没遇到你说的这样的性能需求过,也只好凭感觉随便掰掰:1。 服务器方面:上面说的那样的 PC SERVER需要50台;2。 网络方面:按每个用户 50K,那至少5根百兆带宽独享,估计仅仅网络延迟就大概是 秒一级的;3。 如果有数据库,至少是 ORACLE,最好是 SYSBASE , SQL SERVER 是肯定顶不住的。数据库服务器至少需要 10台4CPU、16G内存的机器;4。 如果有CORBA,那至少再准备10台4CPU、16G内存的机器;再加上负载均衡、防火墙、路由器和各种软件等,总之没个 1000万的

19、资金投入,肯定搞不定。网友 mybasswood 的回复:如果是10万用户的话要看做些什么哈比如对于voip来说,假设有10万用户的话,服务器规定每个 client至少要在3600秒内 到服务器成功报到一次,否则就被服务器cancel掉.client是每隔60秒注册一次.所以就要推算在 3600秒内,每一个client至少成功报到一次是最少的标准 .要10万用户在3600秒内被服务器吃掉才可以 -这是最低要求.最高要求是:在60秒内所有的10万用户去注册,如果服务器在60秒可以都吃掉的话,每 秒种的平均并发差不多是 3334.最低要求是:在3600秒内所有的10用户去注册,如果服务器在3600

20、秒内都可以吃掉的 话,每秒钟的平均并发用户差不多是 60个.还有一过问题是客户端要在 3600秒内发送至少 60次,至少有一次成功.再加上这些用户分布在全球各地的话 ,这样数值应该还会有变化的.下面是偶的看法:给楼主一个建议吧。你在公司中的测试环境是一定的, 你需要做得是现在这个环境中确认一下系统在当前环境下的实际处理能力。如果还有资源,再做一下可伸缩性的测试。然后对测试结果进行分析,对系统的处理能力和可伸缩性做一个描述。当然,要在报告中说明你的测试环境。另外一位网友robust 的留言:你的意思是否想用 10000个用户测试结果来推测一下 10万个用户?还是如有些老兄说的,测试一下什么伸缩性

21、测试.然后也来个报告,无非也是想用1万个来 推测10万个的情况?(评注:那样的话要你做什么性能测试 ,只要计算一下就可以得性能结果了)还是如有些老兄说的,这一类的性能指标对大多数软件来说没什么实际意义,更多的是对 硬件的要求?(评注:那样的话要你做什么性能测试 ,做什么性能调优,只要计算一下,添加硬件就可以了 .)实际上,实践是检验真理的唯一标准 !这句话才是硬道理.只有真实地测试过才知道.任何推测只是推测,并不能反映真实的情况.至于性能测试工具丄R只是普及率高(市场占有率高),并不是在性能指标上有优势.世界上 比它厉害的工具有不少,举个例子siprent通信公司的avalanche2500,

22、 大型计算机实验室配备的性能测试工具.支持录制/回放,测试结果分析等.它可以模拟从数据层到应用层的协议 (当然也包含http-web), 单个支持100万并发连接.拿它也可以测试100万级的并发性能.又是偶的回复:楼上的提到的见解不错,不过对性能测试的理解有些偏差。先抛开性能测试工具不谈,其实这个问题是讨论到一个性能测试到底该怎么做。简单举个例子,如果你想知道一种新的疫苗对人的作用,是不是要把所有的地球人全部找 来每个人打一针试试呢?当然不是, 只能是通过试验和抽样,然后通过统计学的方法来计算出一个模型,通过样本的表现来估算总体的特征。 这就是统计学研究的领域,。不过请注意,统计学所包含的内容

23、并不是像楼上的老兄所说的一样:只要计算一下就可以得性能结果了。性能测试也同样如此。楼主提到的性能需求应该是系统上线以后可能要面临的压力, 先不讨论这个需求是否准确和有效,我们先假定它是有效的。那么,既然要验证的是系统在上线以后是否有能力应对 10万用户同时在线的情况,那么自然要用生产环境来测试。如果有,那么 0K ,可以作这个测试。至于工具,其实可以由开发人员帮忙写一些简单的脚本负责加压, 再通过其他第三方工具收集测试数据就是了。但是如果没有生产环境, 只有一台双CPU,3G内存的2850服务器,怎么办?这就好像上面提到的例子。可行的方法是在这台服务器上使用不同级别的负载来进行测试, 并根据测

24、试数据获得系统在这种环境下的最佳负载和最大负载, 并根据测试数据对负载和资源消耗的情况进行估算,找到它们之间的关系。一般来说,大型的门户网站不会只用一台超级超级的服务器来承担所有的负载, 因为采用负载均衡和集群技术可以更好的解决这个问题, 一定是多台服务器分布在不同的地方, 内容通过内容分发网络同步到各台服务器上。 用户在访问时,其实是被应用层或者前端设备路由到一个合适的服务器去的。所以在测试时,对于可伸缩性的测试是必需的,一定要了解到 cluster数量增加时,系统的响应能力是否可以线性的增加,也就是说是否可以承受更大的 压力,为更多的用户提供服务。I I最后总结一下,对于性能测试,要作的是

25、确认系统的响应能力,然后看系统是否可以满足 性能需求。11如果大家有不同的见解,欢迎 PK讨论继续偶的回复:to jackloo你所提到的对于硬件资源和软件资源的要求并不完全准确。 因为实际的资源消耗要根据网站所提供的业务类型来推算。对于大多数门户网站来说,可供访问的大多是静态页面。在用户访问时,系统只是返回一 个静态页面给用户,并不需要保持 session,而且这种情况下负载主要集中在 I/O和网络流量方面一一这也是为什么大型门户网站都会采用分布式的方式来部署服务器。 当然,如果使用了 cache,内存的使用会随着服务器运行时间的延长而增加, 但是CPU通常不会成为关键资源。这是门户网站同企业应用或者在线游戏的区别。还是偶:to楼主上面我也提到了,你需要进一步的明确你的测试需求是否有效,合理。性能需求需要根据网站具体提供的业务类型来作为依据进行衡量。就如同上面提到的,是 只提供了静态页面的访问?还是有其他的业务?要区分清楚注册用户、在线用户和并发用户的区别。另外,你最迫切需要担心的并不应该是 LR的license 问题,而是被测的系统能否支持的了几百或者几千并发用户,如果连这个都支持不了,就更不用考虑上万的并发访问了。希望大家有不同的看法和意见都可以写下来,大家一起讨论,共同进步

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1