Openfire 性能优化

Openfire  是一个XMPP协议的IM Server。

 

Openfire使用mysql配合它不知所谓几乎无效的的Cache机制就注定没法支撑高并发，

因此第一步，将数据库切换为比较强一点的MongoDB。

可是MongoDB也是有问题的，在高并发时才会发现，MongoDB的锁表十分严重，

通过调查发现，MongoDB也比较坑爹，他是使用“全局锁”的，也就是说，你更新A表的时候，会锁住B表，数据更新后解锁。

因此做为实时查询数据库即便是使用MongoDB的master/slave模式依然不能胜任。

 

增长解决方案，缓存层，使用redis做为MongoDB的数据缓存，在访问时数据时，首先进入Cache层访问redis，若是没有，再去访问MongoDB，而后再回头填充Redis。

OK，数据源解决了，接下来确认须要在什么地方切入。

 

1，首先是将用户信息数据切换到MongoDB中。并中止Openfire本身的Roster服务，在管理控制台设置 xmpp.client.roster.active = false

2，AuthProvider，这里是登录模块，能够继承接口重写一个属于本身的Provider。

重写authenticate方法，将登录验证请求交给cache层。

3，离线信息的存储在以后也会成为负担，那么继承OfflineMessageStore类，重写属于本身的离线信息策略，将离线信息保存到Redis中。

4，重写状态更新的广播：PresenceUpdateHandler中的broadcastUpdate方法。

 

好了，这时候Openfire已经被修改的面目全非，可是效率已经不可同日而语了。

这时候还有一个问题，就是Openfire没有消息保障机制，也就是说，网络不稳定的时候，客户端异常断线，信息就会发送到空气中，

须要再发送信息的时候实现“握手机制”来保障信息的可靠性。不细说了，本身百度。

 

这时候Openfire的在线用户能够飚到6W无压力，可是死活上不去了，又被限制了。

在error.log中会发现相似 “open files too larger” 一类的错误，这些是linux系统参数：最大文件打开数。

在linux下执行ulimit -a就能观察最大的文件打开数，执行ulimit -n 350000设置为35万，而后kill掉openfire退出控制台，从新链接控制台使其生效，从新启动Openfire。

好吧，这时候用户量能够飙6W以上了。

XMPP服务器的测试工具，比较简单的可使用tsung来实现，简单的配置，模拟成千上万的用户登录，而且能够模拟HTTP等其余请求。

 

接下来就是单台服务器容量的问题了，咱们服务器是Dell R710， 64G内存 16核CPU，15000转硬盘。

服务器在这种架构下在线用户数据在29W左右，几乎已是单台Openfire封顶了。

开始考虑集群，不过Openfire的几种集群都测试过，效果不理想，有一个神马war包的插件，弄上去时好时坏，放弃。

还有一个oracle的集群插件，不过在高压下多台Openfire直接脱离集群，本身玩本身的了。。。日。

 

若是到了十万二十万左右的在线用户级别，就放弃掉Openfire，能够尝试使用tigase试试，或者和咱们同样，本身写通信服务器。

 

 

 如下内容参考文章：http://blog.csdn.net/jinzhencs/article/details/50404574

其余设置以及优化

插件

• Subscription插件：自动赞成好友请求，添加插件后在服务器设置最下面设置方式。

服务器设置

• 把没用的一些设置关掉，例如HTTP绑定等等

优化

• 修改打开最大文件数目：ulimit –n 65535
• 设置服务器缓存大小，系统属性加入：

// 注意不能有空格，特别是 size后面
// -1表明无穷大 100000000便是95M
ClientSessionInfoCache：     cache.ClientSessionInfoCache.size
Roster：                     cache.username2roster.size
user：                       cache.userCache.size
group：                      cache.group.size
groupMeta：                  cache.groupMeta.size
offline message：            cache.offlinemessage.size
offlinePresence：            cache.offlinePresence.size
Last Activity Cache：        cache.lastActivity.size
VCard：                      cache.VCard.size
// 以上都是高压下容易飘红的

 

 

 

 

 

 

 

 

 要重启openfire服务才能更新过来哦

 

 

 

将来须要优化的几个点：

1.加大服务器内存 20G变成150G 2.以前源码修改的是3.10.2,以后把新版本的源码下载下来从新修改,然后打包部署. 以解决3.10.2遗留的BUG（如今4.0beta版本出来了,可能过段时间会开源,改了不少bug） 3.根据需求定制openfire，即去除无用的组件,出去无用的消耗资源的一些cache或hashMap,变量之类 4.移出session,把session存入到redis中。 5.除了session,其余的不少cache(服务器缓存)所有移入redis。

 openfire不使用mysql,使用redis做为数据库存储数据,再作个mysql持久化及主从就好了。

论坛有牛人说过:openfire使用了它那不知所谓的cache(其实就是HashMap),就注定没法支撑数十万链接。 
（强哥说了:HashMap存储超过几万后,会有问题，好像是jdk自带的问题）


另一个最重要的优化的方面，就是保证连上服务器的是 有用 的用户。
譬如咱们服务器以前连了10W，可是其实真正用户绑定并使用XX系统的只有1W，可是10W个客户端倒是连着的。 （举例子，以前咱们的系统就比如进入淘宝后台自动登陆旺旺，那么进淘宝多少人就有多少人登陆了旺旺，可是其实真正使用旺旺的只有十分之一甚至更少，咱们只须要让用户在须要旺旺对话的时候才链接服务器的话，那么瞬间服务器压力能减小 90% 这是比任何优化方案都有效的解决方法。是从业务自己去思考并优化，这个须要集思广益。）