优化openfire服务器,达到单机20万,集群50万

openfire压测概述

个月左右的测试,总算得到预定目标(3台服务器,并发50w用户在线)

测试环境搭建

压测客户端无他-tsung，尝试了windows安装perl失败后，使用centOS6.5作为压测机

压测服务器,因为集群需要大内存,因而安装了64位的centos6.7.

所幸这些都可以使用vmware虚拟机,只要装好一台,通过简单copy就能复制出多台.实际上,一共也就使用了6台硬件设备.

设备类别	台数	系统	虚拟机操作系统	说明
OF服务器	3	i54570,12G,Win7	CentOS6.7 8G	其中一台运行mysql数据库
tsung客户机	3	i54570,4G,Win7	CentOS6.5 1G	虚拟机1G内存,运行3个实例

jvisualvm+mat使用

如果不跑集群,其实openfire还是比较稳定的，单台4G内存情况下，也有运行到25W同时在线的情况。一旦用了hazelcast，反而不稳定了，出现问题就需要使用工具进行定位，看看哪里堵住了。

运行结果与心得:

0.千万不要用OpenJdk的虚拟机,官方推荐用CMS进行GC,那就老实点用JDK7.

1.openfire使用mina作为nio底层实现.实测一秒20-25个新连接还算稳定,超过30个就会堵住.(占用大量内存存储未处理的包-经查,时offlineMessage堵住,tsung去掉发送消息的,就快了)

2.openfire使用hazelcast的缓存机制实现集群。经过实际测试，这货太消耗内存了，20w连接大概需要4G的内存（包含mina连接需要的内存），加上还要互为主备的机制，至少还要1.5G才能实现集群的使用。测试至少要8G内存才行,实际使用推荐12G以上.

3.仅仅是压测同一台服务器,与同时压测多台情况大不相同,后期改进主要集中在数据库性能.(后期改进点-)

4.Linux内核修改limits.conf和net.nf_conntrack_max参数后性能有所提升。

程序优化点：

1.JVM配置优化：

需要自己修改openfire.sh,增加虚假机参数.(hazelcast插件有推荐配置,修改一下就行)

2.offlineMessageStore+squenceManager优化：

前面说过了，mysql最多支持每秒30个的NextID，实际运行offlineMessage会很多，修改使用redis保存离线消息。

3.hazelcast和openfire优化：

hazelcast本身就很多问题，例如一台设备内存满了或者处理超时，那么整个集群就没响应了。如果还是用hazelcast作为集群的缓存，需要剥离到单独的设备上去。

openfire用的是java的序列化，内存用的多，效率慢；hazelcast是支持自定义序列化的，经过比较，我用了kryo作为序列化工具，在对ClientSessionInfo，Roster，RosterItem，User这几个类优化后，内存使用明显小了很多。

SessionManager 把所有的clientSession都放到hashmap中,当用户变得非常大量时候，sessionInfoCache的操作必然影响效率。

4.登录流程简化：

xmpp的登录报文交互太多了，虽然tsung使用最简单的iqauth登录，实际使用还是需要简化登录流程，这点需要客户端配合。