zoukankan      html  css  js  c++  java
  • Openfire 性能优化

    Openfire  是一个XMPP协议的IM Server。

    基于MINA的java nio服务器。

    一般就是使用mysql来作为数据库,保存配置配置信息、离线信息、用户数据。

    官网的数据是支持5000人同时在线,使用connectionManager可以实现支持3.3万人在线。

    这数据一点都不漂亮,只能作为一个类似腾讯通的局域网聊天工具使用。


    首先说点题外话,我测试用connectionManager。

    这是一个openfire提供的连接管理器,作用其实是数据整流。

    源码里是通过阻塞式多线程将信息通过特定端口与openfire提交数据。

    测试之后的结果,这玩意严重影响效率,放弃,我们的目标不只是3.3万人。


    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试试,尽管我没试过,不过看过源码,觉得还是比较可靠。

    或者和我们一样,自己写通讯服务器。

  • 相关阅读:
    cinder支持nfs快照
    浏览器输入URL到返回页面的全过程
    按需制作最小的本地yum源
    创建可执行bin安装文件
    RPCVersionCapError: Requested message version, 4.17 is incompatible. It needs to be equal in major version and less than or equal in minor version as the specified version cap 4.11.
    惠普IPMI登陆不上
    Linux进程状态——top,ps中看到进程状态D,S,Z的含义
    openstack-neutron基本的网络类型以及分析
    openstack octavia的实现与分析(二)原理,架构与基本流程
    flask上下文流程图
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13318407.html
Copyright © 2011-2022 走看看