请选择 进入手机版 | 继续访问电脑版

默认
发表评论 8
[已回复] MobileIMSDK udp压力测试丢包严重?
在进行udp压力测试的时候,发现丢包严重,如下图所示: upd1.png

例如第一条,发了311个包,但只收到310个包,由于该连接没有收到第311个包,接下去就不继续发包了。
而且随着时间的进行,发现很多连接都因为此类问题停下来了。严重影响测试效果。
请问大家该类问题怎么解决?先谢谢了!

[img]file:///C:\Users\admin\Documents\Tencent Files\402725796\Image\C2C\_U[P607XN@{ZB`K(W`D[_SE.png[/img]

[img]file:///C:\Users\admin\Documents\Tencent Files\402725796\Image\C2C\_U[P607XN@{ZB`K(W`D[_SE.png[/img]



即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:[已回复] APP闪退后MobileIMSDK出现不能够正常登录的情况下一篇:[已回复] MobileIMSDK在网络不好的状态下如何处理丢包
评论 8
我来回答你的问题。

首先,这个工具只是一个网友写的个人用的udp压力测试工具,这个工具本身有一些先天不足,你如果发现哪些不合理的地方可以联系一下作者。

这个工具里的多个线程,可能代码里并发处理的不好,有的线程很忙,而且的线程却停止执行。当然,你可以不管这个工具具体的线程怎么工作,因为UDP测试的是数据包的吞吐效率,即使只有一个线程能压到极限也一样有意义,所以,你只要看右上角的总体统计结果就行了。

下方是我压力测试的结果,你可以看到它的单个线程里received和send都是相差1,不可能有这么巧的事,这只能说它这工具的数据统计时,最后一个包的统计可能没有统计进去。
110750tmp3o333u10kkojk.png
签名: 该会员没有填写今日想说内容.
3 楼: river Lv.1 楼主 5 个月前 | 显示全部楼层
多谢@JackJiang,但是由于丢包过于严重,比如开20个连接进行压测,过了一会比如说七八秒后,就剩下10个连接在运行,再过一会,可能就剩2两个甚至1个或0个连接在运行,请问当初压测的时候遇到过此类问题吗?有什么解决思路吗?谢谢!
引用:river 发表于 2016-11-06 21:55
多谢@JackJiang,但是由于丢包过于严重,比如开20个连接进行压测,过了一会比如说七八秒后,就剩下10个连接 ...

这是这个压力测试工具的问题,你可以换个工具比如Apache的JMeter试试。另外,没看到你说的丢包严重问题,你把总的统计结果发上来呢
签名: 该会员没有填写今日想说内容.
5 楼: river Lv.1 楼主 5 个月前 | 显示全部楼层
请看下图,注意标红的部分,随着时间的推移,很多连接就不继续发包了,导致测出的socket吞吐量呈现阶梯式下滑。经抓包测试,是因为udp的丢包造成的。例如某个连接发了一个包,但是没有收到响应包,那么这个连接就不继续发包了,像红框里标红的那部分一样,停下来了。 to52im.png
引用:river 发表于 2016-11-07 10:40
请看下图,注意标红的部分,随着时间的推移,很多连接就不继续发包了,导致测出的socket吞吐量呈现阶梯式下 ...

我不从不看这工具的左边,只看右边的结果。不过你这右边也不正常,为何ReceivedPerSencond是0?你对照着我的图看看呢。

我建议你下载jProfile,压力测试的时候用jProfile观察你的服务端,不知你们是如何修改的,我猜测这后台可能存在线程死锁或资源争用,或者其它问题,不信你们自已深度分析一下
签名: 该会员没有填写今日想说内容.
楼主去看看这个贴子:http://www.52im.net/thread-346-1-1.html,我记得之前这个兄弟做MobileIMSDK测试的时候,群主帮他找出原因是它的服务端没有关闭log4j的日志,导致压力到不了极限,你看看是不是也没有关闭日志,导致压测时磁盘IO争用产生大批线程死锁啥的。
签名: 该会员没有填写今日想说内容.
8 楼: river Lv.1 楼主 5 个月前 | 显示全部楼层
多谢大家,经查询发现丢包主要由公司的网络原因导致的。
引用:river 发表于 2016-11-07 20:52
多谢大家,经查询发现丢包主要由公司的网络原因导致的。

你公司路由器是百十来块钱的家用路由器吗?如果这样的话,压力测试很可能会受此影响。建议你最好用工业级的路由器或者直接用阿里云这样的有专业网络架构的服务器来压测。
签名: 该会员没有填写今日想说内容.

Processed in 0.187500 second(s), 37 queries , Gzip On.

返回顶部