标签:
http://dragonsoar.iteye.com/blog/1567771
1.笔者本人现在在一家创业公司担当整个平台架构的角色,而这家公司是做一移动互联网相关的一些应用产品,由其现在正在和中国最大的互联网公司之一进行合作,负责该互联网公司的手机终端的长连接推送服务,所以有一些总结特在此和大家分享一下。
2.下面这篇文章是笔者在几个月前做的一篇长连接的总结,所以可能写的不是非常严谨,特给javaer们进行一些参考即可,有如下几个数据和大家一起分享下:
1) 单JVM实现了50W以上长连接,每秒消息处理“Hello Word”和心跳包6W次
2)该长连接,不仅实现了手机终端的摸拟,而且该框架也是一个成熟的RPC框架,已经在笔者所在的公司使用。比阿里巴巴开源版本出来的"dubbo"性能要高,而且更节省带宽,大家可以测试比较一下。
3)因为netty支持的长连接,每条连接占有用内存是5K,笔者经过包装之后每条连接占用5.3K, 每条长连接系统要占用8K;所以大家可以计算一下每条长连接一共要消耗的系统内存量。
4)通过“3)”我们可以计算,50W长连接需要多少内存量(JVM):500000*5.3K=2650000K=2.53G,50W长连接需要多少内存量(OS):500000*8K=3.8G
也就是说,50W长连接的话,大约需要总占用系统10G的内存空间(当然这是保守值,也希望大家多测试测试给出更多的一些数据)
3.好了,说了这么多,看看笔者的一些测试数据吧(笔者只是把几个月前的测试邮件内容发出,因为某些原因笔者不能发出现在公司正在使用的完全代码实现)
1)如果要支持这么多的长连接,一定要修改一下系统的一些内核参数,如下:
vi /etc/sysctl.conf net.ipv4.tcp_max_syn_backlog = 65536 net.core.netdev_max_backlog = 32768 net.core.somaxconn = 32768 net.core.wmem_default = 8388608 net.core.rmem_default = 8388608 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_synack_retries = 2 net.ipv4.tcp_syn_retries = 2 net.ipv4.tcp_tw_recycle = 1 #net.ipv4.tcp_tw_len = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_mem = 94500000 915000000 927000000 net.ipv4.tcp_max_orphans = 3276800 #net.ipv4.tcp_fin_timeout = 30 #net.ipv4.tcp_keepalive_time = 120 net.ipv4.ip_local_port_range = 1024 65535 /sbin/sysctl -p 最后个命令是让配置生效的。 vi /etc/security/limits.conf 添加 * - nofile 1006154
注:a.因为移动终端经常会因为网络问题断开,所以要修改内核参数支持连接断开后快速回收
b.OS虽然默认TCP的缓冲内存已经足够大,但是因为系统要支持很多的长连接,所以缓冲内存还需要调整,要不然会发生丢包情况(这个也是笔者当时和58同城的资深VP聊天的时候了解并学习到的)
c.文件句柄数要加大,因为OS默认支持的长连接数量比较小
2)下面是测试的邮件正文
写道
下面是测试数据:
1. 同时在线人数 : 508691
2. JVM 参数配置:
5. 每秒消息数:60000msg/s
6. gc.log 信息如下:
ParNew :是新生代的回收时间,会让整个应用停止,real 是真实的应用停止时间:0.4x
GC[YG occupancy] 这一段是老年代full gc :会让整个应用停止,real 是真实时间,0.42
因为gc 新年代和老年代收回不频繁,所以对应用没有影响。内存我也其实也不想再加了,在60000 个消息并发和50W 心跳包的情况下能做到这个效果,我感觉不错了。
刚才问了手机QQ 的长连接,这前他们是15~20W 长连接一台,现在新的架构也就能做35~40W ,我感觉现在应该行了。
该长连接测试用例,笔者是用summercool-hsf开源框架(笔者的另一个开源的RPC框架)的基础上实现的。笔者正在用grizzly实现另一个手机终端长连接版本,因为grizzly更加节省内存,能支持更多的长连接数量,虽然性能可能不会达到netty,但是对不是高压力该问,但是对长连接数量有非常高要求的应用,grizzly还是非常适合的。笔者因为时间的关系,不再列出grizzly的详细测试数据,后面的章节会继续给出,请大家关注。
标签:
原文地址:http://www.cnblogs.com/lancao008/p/4549911.html