LoadRunner結果分析具体实例.docVIP

  1. 1、本文档共12页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
LoadRunner結果分析具体实例

LoadRunner结果分析具体实例 1.前言: LoadRunner最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了. 针对 Results Analysis我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助. 这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1个人接管的时间在5S内. 2.系统资源: 2.1 硬件环境: CPU:奔四2.8E 硬盘:100G 网络环境:100Mbps 2.2 软件环境: 操作系统:英文windowsXP 服务器:tomcat服务 浏览器:IE6.0 系统结构:B/S结构 3.添加监视资源 下面要讲述的例子添加了我们平常测试中最常用到的一些资源参数.另外有些特殊的资源暂时在这里不做讲解了.我会在以后相继补充进来。 Mercury Loadrunner Analysis中最常用的5种资源. Vuser Transactions Web Resources Web Page Breakdown System Resources 在Analysis中选择“Add graph”或“New graph”就可以看到这几个资源了.还有其他没有数据的资源,我们没有让它显示. 如果想查看更多的资源,可以将左下角的display only graphs containing data置为不选.然后选中相应的点“open graph”即可. 打开Analysis首先可以看的是Summary Report.这里显示了测试的分析摘要.应有尽有.但是我们并不需要每个都要仔细去看.下面介绍一下部分的含义: Duration(持续时间):了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。 Statistics Summary(统计摘要):只是大概了解一下测试数据,对我们具体分析没有太大的作用. Transaction Summary(事务摘要):了解平均响应时间Average单位为秒. 其余的看不看都可以.都不是很重要. 4.分析集合点 在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要知道Vuser是在什么时候集合在这个点上,又是怎样的一个被释放的过程.这个时候就需要观察Vuser-Rendezvous图. 图1 可以看到大概在3分50的地方30个用户才全部集中到start集合点,持续了3分多,在7分30的位置开始释放用户,9分30还有18个用户,11分10还有5个用户,整个过程持续了12分. 图2 上面图2是集合点与平均事务响应时间的比较图. 注:在打开analysis之后系统LR默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下: 点击图上.右键选择merge graphs.然后在select graph to merge with 中选择即将用来进行比较的graph.如图3: 图3 图2中较深颜色的是平均响应时间,浅色的为集合点,当Vuser在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个很大的考验. 接下来看一下与事务有关的参数分析.下看一张图. 图4 这张图包括Average Transaction Response Time和Running Vuser两个数据图.从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser达到15个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许14个用户同时处理事务,Vuser达到30后1分,系统响应时间最大,那么这个最大响应时间是要推迟1分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S内.Vuser数量最多不能超过2个.看来是很难满足用户的需求了. 做一件事有时候上级会问你这件事办得怎么样了.你会说做完一半了.那么这个一半的事情你花了多少时间呢?所以我们要想知道在给定时间的范围内完成事务的百分比就要靠下面这个图(Transaction Response Time(Percentile) 图中画圈的地方表示10%的事务的响应时间是在80S左右.80S对于用户来说不是一个很小的数字,而且只有10%的事务,汗.你觉得这个系统性能会好么! 实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事情我们就要分配适当的时

文档评论(0)

fv45ffsjjI + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档