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

放任无奈 · 发表于 2010-7-19 16:45:32

背景:
一个小系统,用30人跑混合场景,场景运行10小时以上

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

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

云层 · 发表于 2010-7-19 16:53:58

很奇怪为什么请求量下降了，但是带宽没下降，难道是你负载这边有资源泄漏？

skyzhu · 发表于 2010-7-19 17:04:55

有个可能就是重复运行导致交互包的大小增加了，而且服务器处理的响应也增加了
脚本的重复操作如果会增加数据量，导致了每个用户操作的时间有略涨，并且每个包的数据量增加，正好也就吞吐量接近了

混合脚本里有增加数据的、还有查询数据的吧

tttrrryyy · 发表于 2010-7-19 17:27:50

事务成功率的问题

tttrrryyy · 发表于 2010-7-19 17:29:33

补充一下，一般有大量事务失败的测试结果，最好降低压力重测，否则一些性能指标也没多大意义

放任无奈 · 发表于 2010-7-19 18:05:48

原帖由 tttrrryyy 于 2010-7-19 17:29 发表
补充一下，一般有大量事务失败的测试结果，最好降低压力重测，否则一些性能指标也没多大意义

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

[ 本帖最后由放任无奈于 2010-7-19 18:07 编辑 ]

放任无奈 · 发表于 2010-7-19 18:10:21

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

混合脚本里有 ...

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

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

xueying1123 · 发表于 2010-7-20 10:25:18

关注

skyzhu · 发表于 2010-7-20 10:34:45

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

苏高跃 · 发表于 2010-7-20 10:42:12

你设置集合点看看是否有变化？

tttrrryyy · 发表于 2010-7-20 11:17:12

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

kasir2008 · 发表于 2010-7-20 11:19:22

30秒的时候connections降了。。
transactions降了。。
结果。。
美妙点击数也降了。。。。。
so......

skyzhu · 发表于 2010-7-20 11:47:48

楼主就是想知道，为什么都下降了，网络吞吐量没下降

放任无奈 · 发表于 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 编辑 ]

放任无奈 · 发表于 2010-7-20 15:53:18

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

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

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

zl861216 · 发表于 2010-7-21 17:33:46

的确是事务成功率的问题！！！

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

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

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

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

[ 本帖最后由 zl861216 于 2010-7-21 17:37 编辑 ]

放任无奈 · 发表于 2010-7-22 01:28:20

原帖由 zl861216 于 2010-7-21 17:33 发表
的确是事务成功率的问题！！！

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

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

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

所以你的说法是不成立的

zl861216 · 发表于 2010-7-22 11:26:52

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

等你把错误率高的问题给解决了，在发个帖子来，说明一下情况吧~~~

放任无奈 · 发表于 2010-7-22 14:49:33

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

等你 ...

你难道不知道脚本可以设置忽略错误继续运行么?

yzhou452 · 发表于 2010-7-27 20:32:48

你设置了 continue on error 是没错

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

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

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

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

[ 本帖最后由 yzhou452 于 2010-7-27 20:38 编辑 ]

		自动登录	找回密码
密码			(注-册)加入51Testing

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

本帖子中包含更多资源

相关帖子

回复 7# 的帖子

回复 1# 的帖子

回复 12# 的帖子

回复 17# 的帖子

回复 17# 的帖子

站长推荐 /1