1. <span>vi /etc/sysctl.conf
2. net.ipv4.tcp_max_syn_backlog = 65536
3. net.core.netdev_max_backlog =  32768
4. net.core.somaxconn = 32768
5. net.core.wmem_default = 8388608
6. net.core.rmem_default = 8388608
7. net.core.rmem_max = 16777216
8. net.core.wmem_max = 16777216
9. net.ipv4.tcp_timestamps = 0
10. net.ipv4.tcp_synack_retries = 2
11. net.ipv4.tcp_syn_retries = 2
12. net.ipv4.tcp_tw_recycle = 1
13. #net.ipv4.tcp_tw_len = 1
14. net.ipv4.tcp_tw_reuse = 1
15. net.ipv4.tcp_mem = 94500000 915000000 927000000
16. net.ipv4.tcp_max_orphans = 3276800
17. #net.ipv4.tcp_fin_timeout = 30
18. #net.ipv4.tcp_keepalive_time = 120
19. net.ipv4.ip_local_port_range = 1024  65535
20. /sbin/sysctl -p
21. 最后个命令是让配置生效的。
22. vi /etc/security/limits.conf
23. 添加
24. *                -       nofile          1006154</span>

1. 有消息收发之间的间隔，比如说。Client --> Server端发消息。
如果Server端默认1分钟没有收到消息（包括心跳），则断开连接，可配间隔时间。
同理，如果Client端没有Server推过来的消息（包括心跳），则断开连接，可配间隔时间。

当然，如果没有消息，心跳包也是可以Client <--> Server互发的。如果没有消息，心跳就会互发，为了保证长连接不断。如果要是在接收方没有消息过来，则认为连接断了。之前设计这个的时候，就是考虑到了手机端的长连接的各种应用场景。

2. 每个登录用户没有用户session，不过有这个接口，可以每个连接可以添加一个attchment，可以跟据连接绑定信息。
测试的时候没有给attchment加信息。
其实真的不是为了代替他的方案，当时设计的时候就是为了RPC和手机服务端长连接设计的。
用户session信息比较占用内存，我是建议用户session信息放在堆外，这样不影响JVM。

3. 现在内存表现是用的CMS回收策略，所以没有出现full gc回收停顿的情况。但是因为netty的长连接本身就占了5K，而且我们这边又加了一些扩展信息，所以现在一个连接占了5.3K。

4. 为什么说现在超过50W了，是因为现在内存上限设成6G了，然后又进行了50W以上的长连接和每秒60000以上的消息发送（Hello Word）。
年轻代和老年代回收的时间都在0.4秒左右，所以对应用没有影响才敢说50W长连接了。
（注：年轻代回收，其实整个应用会停的，老年代的 full gc也是整个应用会停的；不过gc.log我看了，在0.4秒左右，所以没有影响应用）
（其实理论上还可以加内存，不过没有经过压力测试也没有时间弄了，没有测试机测试一回太累了，不过至少保证50W长连接没有啥问题）
（我估计也差不多了是上限了，应用内存回收已经占了0.4秒了，再加大如果回收时间占有的太长也不好）

5. 之前为什么说加到6G测试后，不行。是因为我发现jvm的年轻代不能开太大，好像年轻代开的太大会影响整个应用的停顿时间。所以这次是把年轻代保持不变，heap推放大到6G，所就是说多出来的2G空间给老年代了。而长连接正好在老年代保存，所以新加的2G给长连接正好把长连接推到了50W长连接。而且还有1G以上的空闲空间，而且老年代的full gc也控制在了0.4秒，我感觉比例正好。

下面是测试数据：

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的详细测试数据，后面的章节会继续给出，请大家关注。

summercool-hsf框架地址（已经在某些公司的大型应用成熟使用1年时间）：http://code.google.com/p/summercool-hsf/

原文

http://dragonsoar.iteye.com/blog/1567771