loadrunner得到的奇怪结果分析图，请各位大侠指点指点

hand_smile

脚本是一个简单的登陆操作
并发用户是50人
有一个SB的事务
最后的分析如图
小女子总觉得这图有点奇怪
看不太懂
贴上图
１。我觉得奇怪的是average transaction 图
为什么中间一段时间什么都没有？
２。并发用户图为什么从12开始，为什么不是从0开始呢？
３。最后一张图的响应时间为什么随着用户增加而减少呢？
４。从这张几图能得出个什么结果
请大侠们帮忙分析分析，我初学loadrunner，先谢谢各位了

sfup_ycd

把完整的脚本贴出来看看

hand_smile

是在run time setting 里去掉的

seasons

Average Action Response Time 为62秒左右，因此在图上只有在62s之后才出现第一个采样点。

PS，SB_1这个Transaction的Response Time为3.2s左右，而整个ACTION为62s，那么剩余那些响应时间去哪里了？
可能1：SB_1这个Transaction仅涵盖了脚本的一小部分，其他部分未定义Transaction

如果在整个Action中只有SB_1这一个Transaction的话，那么就很奇怪了，可能有Think_Time（楼主说去掉了Think Time，是在分析里面去掉还是在Run Time Settings？？）

建议：
性能测试模拟的是大量用户持续请求的过程，如果仅用50并发执行一次的话，本身意义不大。如果能持续运行10分钟以上的话，对于性能分析更有帮助。

个人意见，仅供参考

hand_smile

谢谢楼上的，偶继续学习...

Zee

3，这个问题不明白，说明你在分析方面还不够深入，慢慢学吧。

4，如3.

你后面的问题，显然和场景设置有关系。

hand_smile

ZEE 说的我不是很明白
可能我接触得还不够多

至于场景设置
我都是使用默认的选项，没做任何改动
我后来又跑了几次，发现running vusers有的从0开始的
但是average transaction那个图中间还是有空白的，但是多少不一定

看了大家的分析
我自己也认为是
1. 脚本太简单，时间太短，系统处理得快，所以一下子加载了12个用户
2.　average transaction那个图就像ZEE分析的一样：“并且你的场景总共执行的就不是很长时间，所以导致，事务图中有一段的断开，本来这段时间并不长，因为你的场景很短，所以这个时间就因为本地初始化用户和脚本等问题，而变得非常明显。
”
3.“这种情况非常常见。但是原因各有不同。仅凭现在的信息，估计还不能分析出原因来。可以给你一个建议，去查看时间的消耗，不管通过什么方式，只要知道响应时间消耗在什么地方，就可以分析出原因来，就可以改善。”
－－－－－－这个不大明白
4.　一般分析结果都看那些图呀，要怎么看呀？　我最近看了不少这方面的文章，可是还是挺疑惑的！！拿到图不知道怎么分析，不知道怎么发现问题所在？

后来我试了下复杂的脚本，倒没出现以上的情况，只不过并发数设为100,却在summary　report中最大用户数是62,　难道说其它的失败了？

@ppent: 我忽略了think time

ppent

zee分析的很有道理。不过也有可能是你的action中有个thinktime比较大。
我专门试了一下，看看我这个图和你的像不像。

[ 本帖最后由 ppent 于 2007-12-7 12:07 编辑 ]

cangmang

zee老大说得真好.学到不少东西恩恩

Zee

从上看到下，觉得这个问题不是很明确：

1，场景设置没有详细说明。像导演在11楼提出的问题。只有看图，还能得到一些侧面的信息。

2，你的疑问，感觉不大在点子上。

回答问题如下：

1，硬件并不是很清楚，系统状态不是很清楚，怎么能判断这种图不是正常的呢。比如说：初始化50用户，这里大家也不知道脚本是什么样的，有时只有一个登录，脚本也比较复杂。所以环境并不清楚。这个问题没办法判断。
我的猜测：在初始化之后，执行事务，编译脚本，运行用户，你是一下子加载所有用户，那这里就有可能，你在加载用户的时候，客户机的系统比较忙，CPU的切换可能就比较多，这一段时间，占用内存等也大一些，所以这里我建议你看看本地的CPU计数切换增量和内存的分配。
并且你的场景总共执行的就不是很长时间，所以导致，事务图中有一段的断开，本来这段时间并不长，因为你的场景很短，所以这个时间就因为本地初始化用户和脚本等问题，而变得非常明显。

2，场景是同时加载所有用户，这并不是说同时进入runing状态的就是50用户，初始化也有前有后，CPU也要分时处理（我猜14楼说的拥塞可能是指客户端资源的拥塞），在采样时间内，这个数是不能确定的，要注意的是，图中的数据值不是固定不变的。因为采样的频率有不同。

3，这种情况非常常见。但是原因各有不同。仅凭现在的信息，估计还不能分析出原因来。可以给你一个建议，去查看时间的消耗，不管通过什么方式，只要知道响应时间消耗在什么地方，就可以分析出原因来，就可以改善。

4，你给的图，分析不出结果来。只能猜测一些。提点建议。

hand_smile

原帖由 cuizhihui 于 2007-12-6 11:19 发表
summary的图一般是看不出什么问题的。

那我想找出问题，一般应该看那几个图？

hand_smile

原帖由 yuandjing 于 2007-12-6 10:51 发表
我觉得有一下可能：
1.用VUserGenerator生成的脚本太少，而Controller里又跑一次，所以大多数VUser基本上在空闲
2.你的虚拟用户在5秒内升到50人，太快了，导致网络发生拥塞，这种情况你可以用Web Page Break Down分 ...

为什么太快了还会发生网络拥塞呢？

cuizhihui

summary的图一般是看不出什么问题的。

stone0214

为什么action和sb_1还有end是一起执行的?

stone0214

晕,原来是英语教程...

stone0214

上班时间在看电影,哈哈哈

hand_smile

这是summary的图
大家分析分析

yuandjing

我觉得有一下可能：
1.用VUserGenerator生成的脚本太少，而Controller里又跑一次，所以大多数VUser基本上在空闲
2.你的虚拟用户在5秒内升到50人，太快了，导致网络发生拥塞，这种情况你可以用Web Page Break Down分析一下看看
3.其它地方发生拥塞，你可以纪录一下各个东西（CPU、硬盘、内存等）的利用率和队列长度进行比较来判断

stone0214

原帖由 cuizhihui 于 2007-12-6 10:37 发表
看了下，后面两张图那不是一样的嘛。 只不过横纵坐标换了一下而已。
从组合图中，能看出：
服务器在刚开始加载时，事务响应时间比较长，随着用户的增加，事务响应时间越来越短；
这图说明不了什么问题。

50个虚 ...

说的相当好...关注当中...

cuizhihui

看了下，后面两张图那不是一样的嘛。 只不过横纵坐标换了一下而已。
从组合图中，能看出：
服务器在刚开始加载时，事务响应时间比较长，随着用户的增加，事务响应时间越来越短；
这图说明不了什么问题。

50个虚拟用户只跑了一次，初始12个开始跑，有多种可能，不用太关心这个。
平均事务响应时间图比较怪，建议再多跑几次看看。