|
Openfire 采用Java开发，基于XMPP（Jabber）协议，开源的即时通讯服务器。一直以来，对于服务器的支持最大用户数总是让人感到疑问，官方甚至还是几年前的5k。在熟悉了openfire源码后，我决定花些时间测试一下openfire的极限。经过约1个月左右的测试,总算得到预定目标(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登录，实际使用还是需要简化登录流程，这点需要客户端配合。 |
|
|
