网页站点是什么意思,如东建设网站,定做微信小程序,电子类 购物网站之前讲述过多路复用实现单服百万级别RPS吞吐,但在文中有一点是没有说的就是消息IO合并#xff0c;如果缺少了消息IO合并即使怎样多路复用也很难达到百万级别的请求响毕竟所有应用层面的网络IO读写都是非常损耗性能的#xff08;需要硬件配置很高的服务器#xff09;。这一章… 之前讲述过多路复用实现单服百万级别RPS吞吐,但在文中有一点是没有说的就是消息IO合并如果缺少了消息IO合并即使怎样多路复用也很难达到百万级别的请求响毕竟所有应用层面的网络IO读写都是非常损耗性能的需要硬件配置很高的服务器。这一章主要讲述的是IO合并的应用并通过这个特性实现普通单服务千万级别的消息推送测试。什么是消息IO合并所谓的消息IO合并即是由原来一个消息对应一个网络读写设计成多个消息共享一个网络读写。那这样的设计到底会带来多大的性能提升最简单的对比场就是每次执行1条SQL执行1万次和直接批执行1万条SQL的差别相信做过的朋友一定非常清楚其性能提升的幅度。那在网络通讯中如何设计才能让多个消息进行IO合并呢作者在实际实践中的方式有两种1通过定时器把队列中的所有消息定期合并发送2通过一个状态机归递消息队列一旦队列存在消息一次过合并发送。定时器这种比较损耗性能在连接量大的情况存在延时间相互影响对于后者则比较好控制很多也不存在延时性原理发送消息进队列后和网络发送完成再回到状态机检测消息队列状态即可。 消息推送相对于请求响应来说相还是简单很多的毕竟消息推送是单向并不需要有高效的响应机制。不过对于普通服务器间实现千万级的消息推送还是需要做些规划毕竟是需要在有限的IO读写量的情况来达到这么大规模的消息处理。还有这么大量的消息序列化和反序列化也是一非常损耗性能的事情所以这次实践并没有使用Protobuf而是采用自定义序列化。测试的通讯组件选择Beetlex因为它具备了自动消息合并能力并配合高效的多复路用机制在服务之间进行千万级别的消息推变得简单。测试简述这一次测试主要是向服务端推着一个简单的订单信息由客户每次生成不同的订单信息推送给服务端服务器接收订单消息后进行统计,并计算每秒接收的订单数量。消息结构创建订单基于测试资源有限这次的测试并没像之前跑PRS那样采用Protobuf因为这量的对象处理量实在太大测试的硬件环境不变所以采了自定义的序列化方式具体可以参考源代码。接收端代码由于是接收推送的消息服务端接收消息后统计相关数量即可完成对于之前的RPS测试所需处理的东西就少很多了。推送端压测代码为了防止压爆连接内部的消息队列压测端当连接队列超过2000个消息的时候停止一下。由于采用了消息合并机制所以并不需要太多连接在整个测试过程中开启了三个压测实例每个实例使用5个连接换句话说BeetleX通过15个连接实现千万级消息的推送能力。测试服务器资源这次测试使用了两家云服务器第一家名字就不说了开启了V16核的虚拟服务器内部带宽6G和100万pps,结果实际压测2G带宽就压不上去了刚开始以为是linux系统要配置问题换了windows系统试一下还是不行……最终还是换回了阿里云测在v12核的虚拟服务器上顺利完成了这一次测试。服务端: v12核,24G内存操作系统ubuntu16.04 一台,内网最大带宽4Gb.压测端: v12核,24G内存操作系统ubuntu16.04,内网最大带宽4Gb, 两台(主要测试方式有些暴力一台无法达到压测目标)测试结果二台压测机共开启了3个实例每个实例5个连接每个连接应用层处理的buffer 32k;整个测结果消息推送量达到了1000万个/秒。服务端记录接收IO每秒15000次平均每次receive得到的消息大概在600个左右。以下是测试情况的截图服务程序统计情况服务端CPU情况网络使用情况下功测试代码: https://github.com/IKende/BeetleX/blob/master/samples/MassiveMessagepush.zip原文地址https://www.cnblogs.com/smark/p/9869384.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
