loadrunner–analysis实例结果图表分析.docVIP

这个例子主要讲述的是多个用户同时接管任务，测试系统的响应能力，确定系统瓶颈所在。客户要求响应时间是1个人接管的时间在5S内。打开Analysis首先可以看到的是Summary Report。这里显示了测试的分析摘要，但是我们并不需要每个都仔细去看。下面介绍一下部分的含义：Duration(持续时间)：了解该测试过程持续时间。测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。Statistics Summary(统计摘要)：只是大概了解一下测试数据，对我们具体分析没有太大的作用.Transaction Summary(事务摘要)：了解平均响应时间Average单位为秒。其余的看不看都可以，都不是很重要。1、分析集合点在录制脚本中通常我们会使用到集合点，那么既然我们用到了集合点，我们就需要知道Vuser是在什么时候集合在这个点上，又是怎样的一个被释放的过程。这个时候就需要观察Rendezvous图。(添加新图-vuser-rendezvous打开图) 图1可以看到大概在3分50的地方30个用户才全部集中到start集合点，持续了3分多，在7分30的位置开始释放用户，9分30还有18个用户，11分10还有5个用户，整个过程持续了12分。 2、集合点与平均事务响应时间的比较图。 图2注：打开图的具体步骤:点击图上，右键选择merge graphs，然后在select graph to merge with中选择即将用来进行比较的graph。图2中较深颜色的是平均响应时间，浅色的为集合点，当Vuser在集合点持续了1分后平均响应时间呈现最大值，可见用户的并发对系统的性能是一个很大的考验。3、接下来看一下与事务有关的参数分析。Average Transaction Response Time和Running Vuser两个数据图 图4 从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响，Vuser达到15个的时候平均事务响应时间才有明显的升高，也就是说系统达到最优性能的时候允许14个用户同时处理事务，Vuser达到30后1分，系统响应时间最大，那么这个最大响应时间是要推迟1分钟才出现的，在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作。同时也可以看出要想将事务响应时间控制在10S内，Vuser数量最多??能超过2个，看来是很难满足用户的需求了。4、Transaction Response Time(Percentile)查看百分比 图中画圈的地方表示10%的事务响应时间是在80S左右。80S对于用户来说不是一个很小的数字，而且只有10%的事务，汗！你觉得这个系统性能会好么！实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的，对于那些需要时间的事情我们就要分配适当的时间处理，时间分配的不均匀就会出现有些事情消耗的时间长一些，有些事情消耗的短一些，但我们自己清楚LR同样也为我们提供了这样的功能，使我们可以了解大部分的事务响应时间是多少，以确定这个系统我们还要付出多少的代价来提高它。5、Transaction Response Time(Distribution)-事务响应时间(分布)显示在方案中执行事务所用时间的分布。如果定义了可以接受的最小和最大事务性能时间，可以通过此图确定服务器性能是否在可接受范围内。 很明显大多数事务的响应时间在60-140S。一般多数客户所能接受的最大响应时间也要在20S左右。140S的时间很少有人会去花这么多的时间去等待页面的出现吧！通过观察以上的数据表，我们不难看到此系统在这种环境下并不理想。世间事有果就有因，那么是什么原因导致得系统性能这样差呢？让我们一步一步的分析。系统性能不好的原因多方面，我们先从应用程序看，有的时候我不得不承认LR的功能真的很强大，这也是我喜欢它的原因。 6、页面细分图。（如果analysis中找不到该图，运行之前在run-time-setting中preference勾选pages per second(HTML Mode onlyanalysis中就会有) 一个应用程序是由很多个组件组成的，整个系统性能不好那我们就把它彻底的剖析一下。图片中显示了整个测试过程中涉及到的所有web页。web page breakdown中显示的是每个页面的下载时间。点选左下角web page breakdown展开，可以看到每个页中包括的css样式表，js脚本，jsp页面等所有的属性。在select page to breakdown中选择页面。见图。 在Select Page To Breakdown 中选择35:8888/usertasks