为什么是这样? LR结果分析(多图)
背景:一个小系统,用30人跑混合场景,场景运行10小时以上
最后的结果:
各事务响应时间正常,比较稳定
吞吐量稳定
只有点击率(hits per sec)明显下降,从加载到最大用户开始,就一直下降
(当然每秒事务这种指标同点击率保持一致了)
但其它指标都很正常!!!我百思不得其解啊
按理说,如果服务器处理能力达到瓶颈,应该是吞吐量下降啊
不多说了,上图,大家帮忙分析一下,这是咋回事
很奇怪为什么请求量下降了，但是带宽没下降，难道是你负载这边有资源泄漏？ 有个可能就是重复运行导致交互包的大小增加了，而且服务器处理的响应也增加了
脚本的重复操作如果会增加数据量，导致了每个用户操作的时间有略涨，并且每个包的数据量增加 ，正好也就吞吐量接近了
混合脚本里有 增加数据的、 还有查询数据的吧 事务成功率的问题 补充一下，一般有大量事务失败的测试结果，最好降低压力重测，否则一些性能指标也没多大意义 原帖由 tttrrryyy 于 2010-7-19 17:29 发表 http://bbs.51testing.com/images/common/back.gif
补充一下，一般有大量事务失败的测试结果，最好降低压力重测，否则一些性能指标也没多大意义
从哪看出有大量事务失败了?
total transaction per sec图里失败的事务一直比较少 而且也是逐步下降的 因为总的请求/sec是降低的
[ 本帖最后由 放任无奈 于 2010-7-19 18:07 编辑 ] 原帖由 skyzhu 于 2010-7-19 17:04 发表 http://bbs.51testing.com/images/common/back.gif
有个可能就是重复运行导致交互包的大小增加了，而且服务器处理的响应也增加了
脚本的重复操作如果会增加数据量，导致了每个用户操作的时间有略涨，并且每个包的数据量增加 ，正好也就吞吐量接近了
混合脚本里有...
这个我忘说了 确实有这个情况
我的脚本里有插入数据的事务
也就导致了事务响应时间有缓慢的上升
这块是很正常的
但是数据量很小 对性能是不会构成明显影响的
所以点击率的图表不至于因为这么点数据发生这样剧烈的变化 关注
回复 7# 的帖子
运行时间10小时，每秒操作上百次，才降一半，这已经不算明显了对查询的部分做一下针对性的增量数据性能差看看效果
回复 1# 的帖子
你设置集合点看看是否有变化？ 你的total trans/sec，平均fail 和 pass接近1：4，是理解问题还是数据问题？吞吐量稳定是因为他到瓶颈了，对照并发数看，这个值到顶发生在并发数最高之前，你百兆网卡最大只能撑到这个数值左右，700W Bytes/sec，换成bps试试。后面即使很多请求失败，但成功的请求依然能把带宽撑满。
connections降低也好解释，带宽满了，请求堆积，建立新连接自然也就慢了。
点击数是提交的HTTP请求数，响应时间提高，失败的多了，这个值自然就降了。
解决方案：添加负载机分压重测。 30秒的时候connections降了。。
transactions降了。。
结果。。
美妙点击数也降了。。。。。
so......
回复 12# 的帖子
楼主就是想知道，为什么都下降了，网络吞吐量没下降 原帖由 tttrrryyy 于 2010-7-20 11:17 发表 http://bbs.51testing.com/images/common/back.gif你的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 编辑 ] 原帖由 skyzhu 于 2010-7-20 10:34 发表 http://bbs.51testing.com/images/common/back.gif
运行时间10小时，每秒操作上百次，才降一半，这已经不算明显了
对查询的部分做一下针对性的增量数据性能差看看效果
谢谢
前面说过了
虽然脚本中有插入数据的事务
但这个数据量是非常小的
即时运行10小时后也远远不会造成数据库性能问题
这个可以通过事务的响应时间看到
只有轻微的增长 是符合预期的 的确是事务成功率的问题！！！
不过我不是建议增加负载机，，等楼主，你把错误率很高这个问题给解决掉，我想，你这个问题就不会在出现了
为什么网络带宽没有下降，那是因为，你标记的事务是失败的，但是，事务之前的动作，还是会继续做下去的，只不过到你事务失败这一步的时候，才会停止，那么肯定会一直都是满的
连接数下降，那是因为你这个交易失败了，他的连接数肯定会就是断开了，所以会有所下降。这就是为什么，响应时间没什么太大的变化，而tps下降的原因。
如果楼主，你把用户数设置成10秒一个用户增加的话，效果就是相当的明显了。。。
[ 本帖最后由 zl861216 于 2010-7-21 17:37 编辑 ] 原帖由 zl861216 于 2010-7-21 17:33 发表 http://bbs.51testing.com/images/common/back.gif
的确是事务成功率的问题！！！
不过我不是建议增加负载机，，等楼主，你把错误率很高这个问题给解决掉，我想，你这个问题就不会在出现了
为什么网络带宽没有下降，那是因为，你标记的事务是失败的，但是，事务 ...
忘记说明了
我的脚本设置了 出现错误会继续运行
从场景运行10小时以上也可以看出吧
如果出错就中断是不可能的
所以你的说法是不成立的
回复 17# 的帖子
晕。不是中断，你怎么会那么理解呢。。。只是一个vuser在场景里面去跑的这一次的循环中断了，但是接下来，他还会在继续从头运行的。每到这一步，如果你关联的值取不到，那么他就失败，然后就会从头再来。。。等你把错误率高的问题给解决了，在发个帖子来，说明一下情况吧~~~ 原帖由 zl861216 于 2010-7-22 11:26 发表 http://bbs.51testing.com/images/common/back.gif
晕。不是中断，你怎么会那么理解呢。。。只是一个vuser在场景里面去跑的这一次的循环中断了，但是接下来，他还会在继续从头运行的。每到这一步，如果你关联的值取不到，那么他就失败，然后就会从头再来。。。
等你 ...
你难道不知道脚本可以设置忽略错误继续运行么?
回复 17# 的帖子
你设置了 continue on error 是没错LR里面120秒超时也视为一种error 。。关联不到参数 能把错误日志贴出来么。。 你想象一下一个用户等120秒 10小时呢。。
但是你可以注意看下error的日志
除了关联不到参数 是否还有常见的那个120秒超时。。跑得越久 点击率和TPS越低。。
看不到具体的日志。。我也只是猜测 。。
[ 本帖最后由 yzhou452 于 2010-7-27 20:38 编辑 ]
页:
[1]
2
