51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

12
返回列表 发新帖
楼主: hand_smile
打印 上一主题 下一主题

[原创] loadrunner得到的奇怪结果分析图,请各位大侠指点指点

[复制链接]

该用户从未签到

21#
 楼主| 发表于 2007-12-6 12:12:43 | 只看该作者
原帖由 cuizhihui 于 2007-12-6 11:19 发表
summary的图一般是看不出什么问题的。

那我想找出问题,一般应该看那几个图?
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2007-12-6 12:22:01 | 只看该作者
从上看到下,觉得这个问题不是很明确:

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

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

回答问题如下:

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

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

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

4,你给的图,分析不出结果来。只能猜测一些。提点建议。
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2007-12-7 08:59:01 | 只看该作者
zee老大说得真好.学到不少东西恩恩
回复 支持 反对

使用道具 举报

该用户从未签到

24#
发表于 2007-12-7 12:06:37 | 只看该作者
zee分析的很有道理。不过也有可能是你的action中有个thinktime比较大。
我专门试了一下,看看我这个图和你的像不像。

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

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复 支持 反对

使用道具 举报

该用户从未签到

25#
 楼主| 发表于 2007-12-7 15:02:22 | 只看该作者
ZEE 说的我不是很明白
可能我接触得还不够多

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

看了大家的分析
我自己也认为是
1. 脚本太简单,时间太短,系统处理得快,所以一下子加载了12个用户
2. average transaction那个图就像ZEE分析的一样:“并且你的场景总共执行的就不是很长时间,所以导致,事务图中有一段的断开,本来这段时间并不长,因为你的场景很短,所以这个时间就因为本地初始化用户和脚本等问题,而变得非常明显。

3.“这种情况非常常见。但是原因各有不同。仅凭现在的信息,估计还不能分析出原因来。可以给你一个建议,去查看时间的消耗,不管通过什么方式,只要知道响应时间消耗在什么地方,就可以分析出原因来,就可以改善。”
------这个不大明白
4. 一般分析结果都看那些图呀,要怎么看呀? 我最近看了不少这方面的文章,可是还是挺疑惑的!!拿到图不知道怎么分析,不知道怎么发现问题所在?

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

@ppent: 我忽略了think time
回复 支持 反对

使用道具 举报

该用户从未签到

26#
发表于 2007-12-7 16:15:07 | 只看该作者
3,这个问题不明白,说明你在分析方面还不够深入,慢慢学吧。

4,如3.

你后面的问题,显然和场景设置有关系。
回复 支持 反对

使用道具 举报

该用户从未签到

27#
 楼主| 发表于 2007-12-10 18:05:54 | 只看该作者
谢谢楼上的,偶继续学习...
回复 支持 反对

使用道具 举报

该用户从未签到

28#
发表于 2007-12-11 12:19:03 | 只看该作者
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分钟以上的话,对于性能分析更有帮助。

个人意见,仅供参考
回复 支持 反对

使用道具 举报

该用户从未签到

29#
 楼主| 发表于 2007-12-11 14:56:28 | 只看该作者
是在run time setting 里去掉的
回复 支持 反对

使用道具 举报

该用户从未签到

30#
发表于 2007-12-19 10:12:50 | 只看该作者
把完整的脚本贴出来看看
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-13 13:57 , Processed in 0.068307 second(s), 22 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表