51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6933|回复: 24
打印 上一主题 下一主题

[原创] 为什么是这样? LR结果分析(多图)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-7-19 16:45:32 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
背景:
一个小系统,用30人跑混合场景,场景运行10小时以上

最后的结果:
各事务响应时间正常,比较稳定
吞吐量稳定
只有点击率(hits per sec)明显下降,从加载到最大用户开始,就一直下降
(当然每秒事务这种指标同点击率保持一致了)
但其它指标都很正常!!!我百思不得其解啊
按理说,如果服务器处理能力达到瓶颈,应该是吞吐量下降啊

不多说了,上图,大家帮忙分析一下,这是咋回事






本帖子中包含更多资源

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

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

使用道具 举报

该用户从未签到

2#
发表于 2010-7-19 16:53:58 | 只看该作者
很奇怪为什么请求量下降了,但是带宽没下降,难道是你负载这边有资源泄漏?
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2010-7-19 17:04:55 | 只看该作者
有个可能就是重复运行导致交互包的大小增加了,而且服务器处理的响应也增加了
脚本的重复操作如果会增加数据量,导致了每个用户操作的时间有略涨,并且每个包的数据量增加 ,正好也就吞吐量接近了

混合脚本里有 增加数据的、 还有查询数据的吧
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2010-7-19 17:27:50 | 只看该作者
事务成功率的问题
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2010-7-19 17:29:33 | 只看该作者
补充一下,一般有大量事务失败的测试结果,最好降低压力重测,否则一些性能指标也没多大意义
回复 支持 反对

使用道具 举报

该用户从未签到

6#
 楼主| 发表于 2010-7-19 18:05:48 | 只看该作者
原帖由 tttrrryyy 于 2010-7-19 17:29 发表
补充一下,一般有大量事务失败的测试结果,最好降低压力重测,否则一些性能指标也没多大意义


从哪看出有大量事务失败了?
total transaction per sec图里失败的事务一直比较少 而且也是逐步下降的 因为总的请求/sec是降低的

[ 本帖最后由 放任无奈 于 2010-7-19 18:07 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

7#
 楼主| 发表于 2010-7-19 18:10:21 | 只看该作者
原帖由 skyzhu 于 2010-7-19 17:04 发表
有个可能就是重复运行导致交互包的大小增加了,而且服务器处理的响应也增加了
脚本的重复操作如果会增加数据量,导致了每个用户操作的时间有略涨,并且每个包的数据量增加 ,正好也就吞吐量接近了

混合脚本里有  ...


这个我忘说了 确实有这个情况
我的脚本里有插入数据的事务
也就导致了事务响应时间有缓慢的上升
这块是很正常的

但是数据量很小 对性能是不会构成明显影响的
所以点击率的图表不至于因为这么点数据发生这样剧烈的变化
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2010-7-20 10:25:18 | 只看该作者
关注
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2010-7-20 10:34:45 | 只看该作者

回复 7# 的帖子

运行时间10小时,每秒操作上百次,才降一半,这已经不算明显了
对查询的部分做一下针对性的增量数据性能差看看效果
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2010-7-20 10:42:12 | 只看该作者

回复 1# 的帖子

你设置集合点看看是否有变化?
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2010-7-20 11:17:12 | 只看该作者
你的total trans/sec,平均fail 和 pass接近1:4,是理解问题还是数据问题?
吞吐量稳定是因为他到瓶颈了,对照并发数看,这个值到顶发生在并发数最高之前,你百兆网卡最大只能撑到这个数值左右,700W Bytes/sec,换成bps试试。后面即使很多请求失败,但成功的请求依然能把带宽撑满。
connections降低也好解释,带宽满了,请求堆积,建立新连接自然也就慢了。
点击数是提交的HTTP请求数,响应时间提高,失败的多了,这个值自然就降了。
解决方案:添加负载机分压重测。
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2010-7-20 11:19:22 | 只看该作者
30秒的时候connections降了。。
transactions降了。。
结果。。
美妙点击数也降了。。。。。
so......
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2010-7-20 11:47:48 | 只看该作者

回复 12# 的帖子

楼主就是想知道,为什么都下降了,网络吞吐量没下降
回复 支持 反对

使用道具 举报

该用户从未签到

14#
 楼主| 发表于 2010-7-20 15:39:43 | 只看该作者
原帖由 tttrrryyy 于 2010-7-20 11:17 发表
你的total trans/sec,平均fail 和 pass接近1:4,是理解问题还是数据问题?
吞吐量稳定是因为他到瓶颈了,对照并发数看,这个值到顶发生在并发数最高之前,你百兆网卡最大只能撑到这个数值左右,700W Bytes/sec,换 ...


谢谢你的分析
讨论一下

1.
fail:pass接近1:4确实是个问题
我查过这块
失败的都是一个问题:有个数据关联不到
平均8.9次就有一次关联不到
具体原因还有待查明
这块我确实会优先处理的
而且因为这个失败的事务是在action中的
导致最后的action也是fail状态
所以实际的fail:pass比例会比1:4好很多

2.
百兆网卡吞吐量只能到7M?
我想只有增大并发数,如果吞吐量依然是这个水平才能证明你的推测

3.
另外 从图中可以看到 请求的失败次数并没有增加
而是随着请求总数一起下降的
失败的请求比例是非常小的

[ 本帖最后由 放任无奈 于 2010-7-20 15:50 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

15#
 楼主| 发表于 2010-7-20 15:53:18 | 只看该作者
原帖由 skyzhu 于 2010-7-20 10:34 发表
运行时间10小时,每秒操作上百次,才降一半,这已经不算明显了
对查询的部分做一下针对性的增量数据性能差看看效果


谢谢
前面说过了
虽然脚本中有插入数据的事务
但这个数据量是非常小的
即时运行10小时后也远远不会造成数据库性能问题

这个可以通过事务的响应时间看到
只有轻微的增长 是符合预期的
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2010-7-21 17:33:46 | 只看该作者
的确是事务成功率的问题!!!

不过我不是建议增加负载机,,等楼主,你把错误率很高这个问题给解决掉,我想,你这个问题就不会在出现了

为什么网络带宽没有下降,那是因为,你标记的事务是失败的,但是,事务之前的动作,还是会继续做下去的,只不过到你事务失败这一步的时候,才会停止,那么肯定会一直都是满的

连接数下降,那是因为你这个交易失败了,他的连接数肯定会就是断开了,所以会有所下降。这就是为什么,响应时间没什么太大的变化,而tps下降的原因。

如果楼主,你把用户数设置成10秒一个用户增加的话,效果就是相当的明显了。。。

[ 本帖最后由 zl861216 于 2010-7-21 17:37 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

17#
 楼主| 发表于 2010-7-22 01:28:20 | 只看该作者
原帖由 zl861216 于 2010-7-21 17:33 发表
的确是事务成功率的问题!!!

不过我不是建议增加负载机,,等楼主,你把错误率很高这个问题给解决掉,我想,你这个问题就不会在出现了

为什么网络带宽没有下降,那是因为,你标记的事务是失败的,但是,事务 ...


忘记说明了
我的脚本设置了 出现错误会继续运行
从场景运行10小时以上也可以看出吧
如果出错就中断是不可能的

所以你的说法是不成立的
回复 支持 反对

使用道具 举报

该用户从未签到

18#
发表于 2010-7-22 11:26:52 | 只看该作者

回复 17# 的帖子

晕。不是中断,你怎么会那么理解呢。。。只是一个vuser在场景里面去跑的这一次的循环中断了,但是接下来,他还会在继续从头运行的。每到这一步,如果你关联的值取不到,那么他就失败,然后就会从头再来。。。

等你把错误率高的问题给解决了,在发个帖子来,说明一下情况吧~~~
回复 支持 反对

使用道具 举报

该用户从未签到

19#
 楼主| 发表于 2010-7-22 14:49:33 | 只看该作者
原帖由 zl861216 于 2010-7-22 11:26 发表
晕。不是中断,你怎么会那么理解呢。。。只是一个vuser在场景里面去跑的这一次的循环中断了,但是接下来,他还会在继续从头运行的。每到这一步,如果你关联的值取不到,那么他就失败,然后就会从头再来。。。

等你 ...


你难道不知道脚本可以设置忽略错误继续运行么?
回复 支持 反对

使用道具 举报

该用户从未签到

20#
发表于 2010-7-27 20:32:48 | 只看该作者

回复 17# 的帖子

你设置了 continue on error 是没错

LR里面120秒超时也视为一种error 。。关联不到参数 能把错误日志贴出来么。。 你想象一下一个用户等120秒 10小时呢。。

但是你可以注意看下error的日志

除了关联不到参数 是否还有常见的那个120秒超时。。  跑得越久 点击率和TPS越低。。  

看不到具体的日志。。我也只是猜测 。。

[ 本帖最后由 yzhou452 于 2010-7-27 20:38 编辑 ]
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-8 06:12 , Processed in 0.088534 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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