每秒处理 500W 条消息,人、机为之颤抖

来源: 投稿
2017-11-28

上个周末发布了smart-socket v1.2.0版本,本以为v1.2.0会拖到年底再发布。但是一次无意的测试结果,让我迫不及待的想尽快将smart-socket再次推荐给大家。正如标题所示,500W/秒是本次测试的战绩,截图如下,真实有效:

发表本文是为了描述一下本次的测试步骤,感兴趣的朋友都可以去尝试一下。

有一点要事先说明一下,不推荐使用Mac操作系统进行压测,可能会出现死机的情况。不过在Linux、Windows或者Mac下创建的虚拟机环境中都可以稳定运行,具体测试步骤:

  1. 登录码云下载工程https://gitee.com/smartboot/smart-socket并导入IDE

  2. 先后启动P2PServer、P2PMultiClient

  3. 运行至少两分钟,观察P2PServer控制台统计数据,第二分钟开始的数据为有效测试数据。


数据分析:
数据指标分为:流入流量、流出流量、处理失败消息数、已处理消息量、已处理消息总量。
要评估smart-socket真正的处理能力,个人觉得应该将流入流量与流出流量、请求消息数与响应消息数分别累加统计。这并不是为了让smart-socket有一个漂亮的数据报告,因为无论是何种类型的流量和消息数,都是经由smart-socket处理的。一分钟内,它不仅完成了近10G流量的读入,还输出了近10G的流量。

按照该思路smart-socket本次的性能表现应为:

  • 处理流量总数近20G,

  • 消息总数超6亿,

  • 平均处理消息数约1000W/秒。

smart-socket已经达到性能极限了吗?当然不是,它还有改进的空间,我知道!作为一款只有区区700多行代码的通信框架,smart-socket极简、易用、高性能的特性,相信可以作为您学习、工作非常不错的一个选择。

展开阅读全文
180 收藏
分享
加载中
精彩评论
做技术的他妈的玩什么uc,一帮傻逼样的标题
2017-11-28 11:22
44
举报
我看了下测试的内容, 10个客户端连1个服务器, 客户端死循环地发33字节长的数据, 服务器收到后回给客户端.
测试结果基本上压到极好的结果, 原因一是本机对本机的数据传输开销比真正的网络栈少很多; 原因二是只在很少的连接上持续压数据,这对任何网络接口(BIO,NIO,AIO)都是开销非常小的行为.
建议分两台物理机测试客户端和服务器, 连接数上到1W再测结果, 会更有意义.
2017-11-28 14:51
20
举报
既然占到头条位置了, 我想客观地说明一下:
这个测试几乎只是在测试CPU和内存的性能, 跟网卡和系统网络协议栈没什么关系, Win10的任务管理器也能看出, 压测的时候网卡毫无压力. 单机内的网络不管用什么框架都没什么性能问题, 关键是物理机之间的大规模连接的网络交互才真正考验网络框架.
另外, 自从Java7面世带来了AIO, JDK已经做了很好的封装, 使上层编写网络应用非常便捷, 所以像几百行写个网络框架得以轻易实现. 所以即使测试得到好成绩, 也应该主要归功于Java本身, 要低调不要居功自傲, 并把主要精力放在上层实际应用提供更便捷更高性能的中间件.
2017-11-29 12:03
14
举报
看到这种刺眼、浮夸的标题,本不想点进来,就是想看看评论,高手其实在评论里
2017-11-29 22:56
5
举报
吐了,看到这样的标题就反胃了,你们去做销售吧,求你们了
2017-11-29 14:06
4
举报
最新评论 (54)
首先支持+攒 作者 . 其次希望多说说 与netty区别,用途各自特点
2018-03-30 17:11
0
回复
举报
666
2018-03-30 09:11
0
回复
举报
厉害,赞作者一个,那些酸的人,理论家,别在这BB,你们自己搞一个去,能达到这个量级再来
2018-02-06 09:48
0
回复
举报
擦,标题党啊
2017-12-15 16:00
0
回复
举报
......测试结果应该贴硬件配置 资源的吧。。。。
2017-11-29 23:48
0
回复
举报
看到这种刺眼、浮夸的标题,本不想点进来,就是想看看评论,高手其实在评论里
2017-11-29 22:56
5
回复
举报

引用来自“Tuco”的评论

我做的应用,非常简单的实时流媒体流转发,UDP层面的,无条件转发,c++实现,极限能跑到并发8000路,每一路每秒50个包,centos,超线程后24核的服务器,到这个数字的时候,CPU已经快没了,再往上上,就会有明显的丢包。而且,这个需要支持多通道的网卡,也就是网卡支持将计算任务分发到多个CPU核上。测试的时候,用了双网卡绑定,8通道,两块可以用16个CPU核。如果不支持多通道的网卡,并没有做双网卡符合分担,远远上不了这个数字。我的数字是每秒8000*50=40万个包。比不了,比不了。。。

引用来自“哈库纳”的评论

你的单个数据包大,自然比不了了。

引用来自“Tuco”的评论

是大一点,但是这不是关键。性能消耗发生在小包密集的读取发送上。至于读一次,是100个字节还是10个字节,区别并不大
小包密集发送是很考验 cpu 的。
2017-11-29 18:03
0
回复
举报

引用来自“Tuco”的评论

我做的应用,非常简单的实时流媒体流转发,UDP层面的,无条件转发,c++实现,极限能跑到并发8000路,每一路每秒50个包,centos,超线程后24核的服务器,到这个数字的时候,CPU已经快没了,再往上上,就会有明显的丢包。而且,这个需要支持多通道的网卡,也就是网卡支持将计算任务分发到多个CPU核上。测试的时候,用了双网卡绑定,8通道,两块可以用16个CPU核。如果不支持多通道的网卡,并没有做双网卡符合分担,远远上不了这个数字。我的数字是每秒8000*50=40万个包。比不了,比不了。。。

引用来自“dwing0”的评论

你这个才是真正的网络通信, 而且是具体业务的, 这个结果已经不错了, 不能跟loopback的网络相提并论的.
不过UDP比TCP协议栈简单一些, 开销也小, 就是流量过大容易丢包.
udp应该要性能更高一些
2017-11-29 17:23
0
回复
举报

引用来自“Tuco”的评论

我做的应用,非常简单的实时流媒体流转发,UDP层面的,无条件转发,c++实现,极限能跑到并发8000路,每一路每秒50个包,centos,超线程后24核的服务器,到这个数字的时候,CPU已经快没了,再往上上,就会有明显的丢包。而且,这个需要支持多通道的网卡,也就是网卡支持将计算任务分发到多个CPU核上。测试的时候,用了双网卡绑定,8通道,两块可以用16个CPU核。如果不支持多通道的网卡,并没有做双网卡符合分担,远远上不了这个数字。我的数字是每秒8000*50=40万个包。比不了,比不了。。。

引用来自“哈库纳”的评论

你的单个数据包大,自然比不了了。
是大一点,但是这不是关键。性能消耗发生在小包密集的读取发送上。至于读一次,是100个字节还是10个字节,区别并不大
2017-11-29 17:22
0
回复
举报

引用来自“Tuco”的评论

我做的应用,非常简单的实时流媒体流转发,UDP层面的,无条件转发,c++实现,极限能跑到并发8000路,每一路每秒50个包,centos,超线程后24核的服务器,到这个数字的时候,CPU已经快没了,再往上上,就会有明显的丢包。而且,这个需要支持多通道的网卡,也就是网卡支持将计算任务分发到多个CPU核上。测试的时候,用了双网卡绑定,8通道,两块可以用16个CPU核。如果不支持多通道的网卡,并没有做双网卡符合分担,远远上不了这个数字。我的数字是每秒8000*50=40万个包。比不了,比不了。。。
你的单个数据包大,自然比不了了。
2017-11-29 16:59
0
回复
举报
更多评论
78 评论
180 收藏
分享
返回顶部
顶部