51Testing软件测试论坛

标题: loadrunner得到的奇怪结果分析图，请各位大侠指点指点 [打印本页]

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

作者: 杀手太冷 时间: 2007-12-5 18:20
关注中哈~~

作者: stone0214 时间: 2007-12-5 18:29
３。最后一张图的响应时间为什么随着用户增加而减少呢？

我想这个应该是因为server的压力小了,所有对于任何请求响应的更快了,其他的还不知道.等待其他人更新

作者: stone0214 时间: 2007-12-5 18:43
１。我觉得奇怪的是average transaction 图
为什么中间一段时间什么都没有？

有可能是你选了load all Vuser simultaneously 和Initialize all Vuser before run造成的运行前把所有Vuser初试化,然后ramp up又没有限制...所以一下就上来了12个Vuser

以上只是猜测...

作者: zitong 时间: 2007-12-6 09:10
对于average transaction 这张结果图,我也曾遇到过这个奇怪的问题,但是还没有弄明白原因,关注中........

作者: 板砖 时间: 2007-12-6 09:52
是不是只执行了一次事务?

作者: stone0214 时间: 2007-12-6 09:54
标题: 回复 6# 的帖子
和只执行一次transaction有关系吗?
能跟我说说么?

作者: hand_smile 时间: 2007-12-6 10:00
@stone0214
我选了load all Vuser simultaneously
但是Initialize all Vuser before run没有选

搞不明白咋回事。。求助～

作者: hand_smile 时间: 2007-12-6 10:03
run logic 是只有一次

作者: stone0214 时间: 2007-12-6 10:14
标题: 回复 8# 的帖子
我觉得跑脚本之前没有初试化所有用户一次性跑12个用户还是可能的,但是条件是application非常的小...你手动打开的时候也很快...

作者: xingcyx 时间: 2007-12-6 10:33
LZ的场景设置是怎么样的？
持续运行了多少时间？事务通过了多少，失败了多少？
这些信息对于判断你出现的问题也是很关键的。

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

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

作者: stone0214 时间: 2007-12-6 10:39

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

50个虚 ...

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

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

作者: hand_smile 时间: 2007-12-6 10:52
标题: summary的图
这是summary的图
大家分析分析
[attach]35760[/attach]

作者: stone0214 时间: 2007-12-6 11:04

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

作者: stone0214 时间: 2007-12-6 11:04
晕,原来是英语教程...

作者: stone0214 时间: 2007-12-6 11:08
为什么action和sb_1还有end是一起执行的?

作者: cuizhihui 时间: 2007-12-6 11:19
summary的图一般是看不出什么问题的。

作者: hand_smile 时间: 2007-12-6 11:59

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

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

作者: hand_smile 时间: 2007-12-6 12:12

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

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

作者: Zee 时间: 2007-12-6 12:22
从上看到下，觉得这个问题不是很明确：

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

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

回答问题如下：

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

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

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

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

作者: cangmang 时间: 2007-12-7 08:59
zee老大说得真好.学到不少东西恩恩

作者: ppent 时间: 2007-12-7 12:06
zee分析的很有道理。不过也有可能是你的action中有个thinktime比较大。
我专门试了一下，看看我这个图和你的像不像。

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

作者: hand_smile 时间: 2007-12-7 15:02
ZEE 说的我不是很明白
可能我接触得还不够多

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

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

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

@ppent: 我忽略了think time

作者: Zee 时间: 2007-12-7 16:15
3，这个问题不明白，说明你在分析方面还不够深入，慢慢学吧。

4，如3.

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

作者: hand_smile 时间: 2007-12-10 18:05
谢谢楼上的，偶继续学习...

作者: seasons 时间: 2007-12-11 12:19
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 时间: 2007-12-11 14:56
是在run time setting 里去掉的

作者: sfup_ycd 时间: 2007-12-19 10:12
把完整的脚本贴出来看看

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)