LoadRunner结果分析

    Win7系统,2G内存,IE8浏览器

    系统结构:B/S系统

1．分析集合点

在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要知道Vuser是在什么时候集合在这个点上,又是怎样的一个被释放的过程.这个时候就需要观察Vuser-Rendezvous图:下图为Rendezvous - Average Transaction Response Time的组合图

                                图1

可以看到大概在1分30的地方20个用户才全部集中到start集合点,持续了15分多,在16分的位置开始释放用户,16分30还有19个用户,17分10还有16个用户,17分30海油12个用户,整个过程持续了18分.

图中绿色颜色的是平均响应时间,紫色的为集合点,当Vuser在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个很大的考验.

接下来看一下与事务有关的参数分析.下看一张图.

                                图2

这张图包括Average Transaction Response Time和Running Vuser两个数据图.从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser达到10个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许10个用户同时处理事务,Vuser达到20后1分,系统响应时间最大,那么这个最大响应时间是要推迟1分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S内.Vuser数量最多不能超过2个.

下图为给定时间的范围内完成事务的百分比 (Transaction Response Time(Percentile)

根据图和下面的文字说明可以看到10%的事务的响应时间是在90-95S左右.平均90S对于用户来说不是一个很小的数字,而且只有10%的事务,性能可能不是很好

    Transaction Response Time(Distribution)-事务响应时间(分布)显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.

很明显大多数事务的响应时间在30-40S.响应时间可能有点慢

通过观察以上的数据表.我们不难看到此系统在这种环境下并不理想.