loadrunner-analysis实例结果图表分析

这个例子主要讲述的是多个用户同时接管任务，测试系统的响应能力，确定系统瓶颈所在。客户要求响应时间是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，然后在selectgraph 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)查看百分比