51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 11235|回复: 21
打印 上一主题 下一主题

[原创] 平均事务响应时间图分析

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-3-11 10:24:48 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
各位好,请大家帮忙分析如图的平均事务响应时间图

图中那个红色部分时间为什么会跳的那么高,不是很明白,请大家帮忙

测试过程中,发现那个时间跳的很高的那个时间点,恰好是虚拟用户开始释放的时间点

就是不是很明白为什么会这样

B/S模型,录制的操作很简单是这样的

使用IE7,输入URL,点击转到按钮,就这个动作

本帖子中包含更多资源

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

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

22#
 楼主| 发表于 2010-3-31 16:57:55 | 只看该作者
暂时还未找到答案
回复 支持 反对

使用道具 举报

该用户从未签到

21#
发表于 2010-3-26 17:07:24 | 只看该作者
r看样子楼主没有找到答案.
回复 支持 反对

使用道具 举报

该用户从未签到

20#
发表于 2010-3-23 13:46:53 | 只看该作者
你可以加一些调试的语句,print什么的,这样就知道脚本是怎么运行的。
回复 支持 反对

使用道具 举报

该用户从未签到

19#
 楼主| 发表于 2010-3-23 10:37:49 | 只看该作者
OK,我再看看,一般什么样的情况会导致,事务运行的状态为停止呢
回复 支持 反对

使用道具 举报

该用户从未签到

18#
发表于 2010-3-23 10:30:22 | 只看该作者
Abort was called from an action.
这是你log里面的,说明是你脚本中有stop的动作。
再查查你脚本吧。
回复 支持 反对

使用道具 举报

该用户从未签到

17#
 楼主| 发表于 2010-3-22 22:13:18 | 只看该作者
不会吧,那为什么是最后一次不迭代啊,

前面的能迭代呢,
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2010-3-19 15:11:34 | 只看该作者
好像最后一次迭代没有执行,是不是你的迭代的脚本写的不对?
回复 支持 反对

使用道具 举报

该用户从未签到

15#
 楼主| 发表于 2010-3-18 17:53:34 | 只看该作者
日志文件

本帖子中包含更多资源

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

x
回复 支持 反对

使用道具 举报

该用户从未签到

14#
 楼主| 发表于 2010-3-18 17:46:59 | 只看该作者
日志文件见附件
回复 支持 反对

使用道具 举报

该用户从未签到

13#
 楼主| 发表于 2010-3-18 17:44:20 | 只看该作者
请高手帮忙看一下日志文件,从日志文件中来看

最后一次迭代,事务URL的状态为停止,而不是通过或失败,并且发费了15秒多的时间

Action.c(4): Notify: Transaction "URL" started.        [MsgId: MMSG-16999]
Action.c(6): Rendezvous URL        [MsgId: MMSG-17988]
Action.c(6): Notify: Transaction "URL" ended with "Stop" status (Duration: 15.0079).        [MsgId: MMSG-16873]Abort was called from an action.        [MsgId: MMSG-10447]
Ending Vuser...        [MsgId: MMSG-15966]

有好几个虚拟用户的日志文件,最后一次迭代都是这种情况

请高手帮忙分析一下
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2010-3-17 09:34:45 | 只看该作者
最根本的方法还是看log,看那个时间到底在做什么。
回复 支持 反对

使用道具 举报

该用户从未签到

11#
 楼主| 发表于 2010-3-16 18:05:48 | 只看该作者
但是为什么我每跑一次都出现这样的现象,这就不正常了

并且时间突起来的时间,吞吐量和点击率明显下降,说明服务器那个时候根本没有处理请示
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2010-3-16 09:47:26 | 只看该作者
机器有时候卡一下(比如LR统计数据时卡了一下)就可能出现这样的情况,我认为挺正常的,没什么关系,使用90 Percent一分析,直接无视。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2010-3-16 09:30:46 | 只看该作者
是不是正好那个时候有比较多的用户同时做请求啊 如果有log的话可以看一下server log.
回复 支持 反对

使用道具 举报

该用户从未签到

8#
 楼主| 发表于 2010-3-16 09:12:57 | 只看该作者
看一下这几个图片

服务和负载机不是同一台机器

网络延迟,我在页面细分时,看网络传输时间并没有那么长的时间

即使是网络延迟,应该也不可能延长那么长的时间吧

本帖子中包含更多资源

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

x
回复 支持 反对

使用道具 举报

该用户从未签到

7#
 楼主| 发表于 2010-3-16 08:43:33 | 只看该作者
CPU不太可能,我看了,使用率很低

那个突上去的时间,正好是虚拟用户跑结束要释放的时间点

网络延迟为什么都是在那一块呢,同样这个脚本,有时候跑出来的平均事务响应时间是正常的,不知道为什么
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2010-3-13 15:13:03 | 只看该作者

帮助顶

有可能是网络或cpu原因引起。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2010-3-13 10:36:52 | 只看该作者
你说的用户释放 是不是 事物结束时间点?
如果是 你要考虑网络延迟状况,你眼睛看到的时间点跟分析的时间点是有点误差时间区
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2010-3-13 10:18:29 | 只看该作者
帮顶,期待问题解决 。。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-28 06:32 , Processed in 0.080103 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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