优化openfire服务器,达到单机20万,集群50万
2016-06-17 14:25
363 查看
原文地址:
http://www.android100.org/html/201601/28/212759.html
openfire压测概述
Openfire 采用Java开发,基于XMPP(Jabber)协议,开源的即时通讯服务器。一直以来,对于服务器的支持最大用户数总是让人感到疑问,官方甚至还是几年前的5k。在熟悉了openfire源码后,我决定花些时间测试一下openfire的极限。经过约1个月左右的测试,总算得到预定目标(3台服务器,并发50w用户在线)
测试环境搭建
压测客户端无他-tsung,尝试了windows安装perl失败后,使用centOS6.5作为压测机
压测服务器,因为集群需要大内存,因而安装了64位的centos6.7.
所幸这些都可以使用vmware虚拟机,只要装好一台,通过简单copy就能复制出多台.实际上,一共也就使用了6台硬件设备.
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登录,实际使用还是需要简化登录流程,这点需要客户端配合。
http://www.android100.org/html/201601/28/212759.html
openfire压测概述
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个实例 |
如果不跑集群,其实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登录,实际使用还是需要简化登录流程,这点需要客户端配合。
相关文章推荐
- 马化腾亲自“站台” 企业微信和个人微信互通能带来什么?
- [转][XMPP] gtalk & XMPP & libjingle
- CentOS 6部署Openfire 扩展平台聊天功能。
- centos 安装openfire
- IM 协议的分析和选取 (XMPP&WebSocket)
- 使用openfire,spark,fastpath webchat搭建在线咨询服务详细图文解说
- 网友在疑问:你说百度IM还有机会吗?
- android聊天软件的实现
- XMPP学习笔记(1)
- 音视频源代码、C++音视频源代码、C#音视频源代码、主流开发语言音视频源代码
- 什么是双机热备、原理应用、音视频、即时通讯、IM当中的双机热备应用
- openfire 虚拟内存
- Ubuntu12.04(64bit)上部署编译运行Openfire+Spark环境
- 在Openfire源码中添加自己的插件
- openfire资源
- openfire 部署连接数据库失败
- openfire集群
- openfire集群+nginx负载均衡
- openfire在windows环境和linux环境下的配置