openfire极限优化

日志优化  

  1. 默认是 用info 级别,最好不用openfire原生的打日志方式。
  2.   离线消息用存储不打回方式,不要用打回方式   xmpp.offline.type=store_and_drop
  3.    ConnectionHandler 收到异常,关闭链接的异常日志,用debug级别
  4. 会有很多debug级别的日志,打印出消息体。这种需要避免掉,    例如,logger.debug("msg resend by old session: " + msg.toXML()); 虽然是debug,不会打印日志,但是会执行msg.toXML(),而这个是个耗时操作。可改成如下写法:
          if(logger.isDebugEnabled()){
                         logger.debug("msg resend by old session: " + msg.toXML());
            }

多人聊天优化

    1:对于新加入的房间,不要显示历史聊天记录history.type=none
    2:多人聊天的聊天记录不要存储到db    LocalMUCRoom.broadcast   mucService.logConversation(this, message, senderAddress);
    3 :对于多人聊天,创建房间,进入房间,退出房间频率过高会导致内存占用过高。org.jivesoftware.openfire.event.GroupEventDispatcher
openfire极限优化

登录优化

  1. 用最简单的ssl验证方式,也就是plain 用base64编码 (replace into ofProperty values ("sasl.mechs","PLAIN");)
  2. 不用安全传输,也就是关掉tls(replace into ofProperty values ("xmpp.client.tls.policy","disabled");)
  3. xmpp登录流程 有11步包交互,非常复杂和繁琐。可以简化登录流程。运用快速登录,现已经简化到4步,只发stream包和auth包。
  4. 重写AuthProvider,返回一定要快

离线消息

    离线消息默认是用db存储,并且可以设定策略限制每个用户的存储空间。在移到网络下,会经常出现对方不在线,需要存离线的情况,并且每次登录都需要取离线,所以是一个频繁和耗时操作。
  1. 离线改用缓存存储
  2. 设置离线消息用存储不打回方式,会少一次网络通信(通知发送方)

链接管理器

   链接管理器的运用,可以极大缓解openfire的链接压力。如果直连openfire,每个链接会占有一个文件句柄,每个socket会分配读写缓冲区。会占用大量内存资源。做过测试,当同时在线达到1W,
NIOConnection 将会占用3G多内存。是openfire占用内存最多的。如果用链接管理器,openfire只需要关注业务处理,不需要处理链接建立,释放,最重要的是,只需要维护几十个与链接管理器建立的长链接。当然官方的提供的链接管理器,版本非常老,网络性能低下(链接管理器与openfire之间的通信竟然是直接用的socket,流式处理)。
1台openfire前面可以放多个链接管理器。
  1. 链接管理器与openfire之间通信方式改用mina。
  2. 链接管理器与openfire通信本身线程池优化,直接用mina提供的IoProcesser线程池
      

反空闲优化

   设置idletime,防止空闲链接占用资源。openfire提供了好几种方式
    1. 客户端主动发pingiq包,服务器会回包
    2. 服务端主动发ping包,客户端会回包
    3. 运用mina本身提供的keep-alive机制

线程池优化

    线程池优化的目的,是使系统使用较少的线程去高效的完成工作。具体分析需要用jstack来分析每一个线程。一般来讲openfire维护几百个线程(包括插件占用的)是比较正常的。
  1. 1~2个SocketAcceptor线程来处理建立链接,
  2. IoAcceptor用于监听客户端的连接,每监听一个端口建立一个线程
  3. xmpp.processor.count=48 用48个线程处理SocketAcceptorIoProcessor,用来IO处理。
  4. xmpp.processor.threads.standard=64 xmpp.multiplex.processing.threads =64 用来做业务处理,也就是filter处理的过程
  5. openfire默认是用cpu核数个线程来处理epoll,如果cpu个数比较过多的话,可以减少线程数到8个,可用new NioSocketAcceptor( executor,processorCount );

网络参数优化

  1. net.ipv4.neigh.default.gc_stale_time = 120
    net.ipv4.conf.all.rp_filter = 0
    net.ipv4.conf.default.rp_filter = 0  //lvs内网通信需要
    net.ipv4.conf.default.arp_announce = 2
    net.ipv4.conf.all.arp_announce = 2
    net.ipv4.tcp_max_tw_buckets = 5000
    net.ipv4.tcp_syncookies = 1  //启用syn cookies
    net.ipv4.tcp_max_syn_backlog = 8096 //同时,并发建立的链接不能及时处理的放到队列的上限
    net.ipv4.tcp_synack_retries = 2 //syn ack没有收到,最多做2次重试
    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    net.ipv4.conf.lo.arp_announce = 2
    net.ipv4.conf.eth0.rp_filter = 0
    net.ipv4.conf.eth1.rp_filter = 0
    net.ipv4.tcp_tw_reuse = 1 
    net.ipv4.tcp_tw_recycle = 1
    net.ipv4.tcp_fin_timeout = 10  //对于进入fin状态的,关掉链接的超时时间
    net.ipv4.ip_local_port_range = 1024 65000
    net.ipv4.tcp_rmem = 4096 16380 4194304  //读缓冲区(tcp是双工通道,读写通道是分离的)
    net.ipv4.tcp_wmem = 4096 16380 4194304 //写缓冲区
    net.ipv4.tcp_mem = 678558  1004745  1457116 //总的内存
    vm.overcommit_memory = 1
     
    xmpp.socket.backlog=8096
    xmpp.socket.buffer.receive=-1(表示用系统设置)
    xmpp.socket.buffer.send=-1(表示用系统设置)
    xmpp.socket.linger=-1是否运用优雅关闭
    xmpp.socket.tcp-nodelay= true是否用Nagle算法
     
     
     
     
     
     
     
    vm.swappiness = 0
    net.ipv4.neigh.default.gc_stale_time=120
    net.ipv4.conf.all.rp_filter=0
    net.ipv4.conf.default.rp_filter=0
    net.ipv4.conf.default.arp_announce = 2
    net.ipv4.conf.all.arp_announce=2
    net.ipv4.tcp_max_tw_buckets = 5000
    net.ipv4.tcp_syncookies = 1
    net.ipv4.tcp_max_syn_backlog = 8192 
    net.ipv4.tcp_synack_retries = 2
    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    net.ipv4.conf.lo.arp_announce=2
    net.ipv4.conf.eth0.rp_filter = 0
     
    net.core.rmem_default = 256960
    net.core.rmem_max = 513920
    net.core.wmem_default = 256960
    net.core.wmem_max = 513920
    net.core.netdev_max_backlog = 2000
    net.core.somaxconn = 8192
    net.core.optmem_max = 81920
    net.ipv4.tcp_mem = 131072  262144  624288
    net.ipv4.tcp_rmem = 8760  256960  6088000
    net.ipv4.tcp_wmem = 8760  256960  6088000
    net.ipv4.tcp_keepalive_time = 1800
    net.ipv4.tcp_keepalive_intvl = 30
    net.ipv4.tcp_keepalive_probes = 3
    net.ipv4.tcp_sack = 1
    net.ipv4.tcp_fack = 1
    net.ipv4.tcp_timestamps = 0
    net.ipv4.tcp_window_scaling = 1
    net.ipv4.tcp_tw_reuse = 1
    net.ipv4.tcp_tw_recycle = 0
    net.ipv4.tcp_fin_timeout = 30
    net.ipv4.ip_local_port_range = 1024 65535
     
     
     

StringBuilder优化

 默认情况下,StringBuilder对象最多可容纳16个字符之前自动调整大小本身。设置合适的长度,有助于防止JVM浪费时间申请内存和字符串复制。作为一个例子,因为我们知道stream header的大小为约500个字符,我们可以大小StringBuilder的恰如其分。
 

packet.createCopy

    packet是用的DOM4J XML模型,所以复制很消耗性能。尽量避免用packet.createCopy
 

System.currentTimeMillis()

   统计,打印日志,openfire本身会频繁调用System..currentTimeMillis()。System.currentTimeMillis()的调用比new一个普通对象要耗时的多,因为会有一次系统调用。对于一些对时间精确度不是很高的情况下,可以改用内存存储一小段时间内的值。
 

禁用roster花名册、禁用presence包通讯

   如果可能的话,可以禁用roster服务,改用http接口拉取好友列表,并且客户端做缓存。
 

ping包优化

    不管是服务端主动发ping,还是客户端发ping包,不可否认的是,ping包占据openfire处理消息量最大一类。如下图
openfire极限优化
差不多是消息发送的10倍左右,虽然ping包处理很简单,耗时很短,但量大了,还是需要考虑优化的。我的优化方案就是把对于客户端发的ping包处理移到链接管理器去。
 
 
A->server回执优化

由于我们的IM系统是做了送达,也就是服务端收到消息后,会显示的给用户发个回执包。和ping包优化机制一样,链接管理器收到消息后,就直接返回回执包。

 
id序列号生成器
SequenceManager锁的粒度比较大,并发比较高的时候,就经常会锁住。需要重写。
 
 
上一篇:Solr在结果返回函数值


下一篇:我的java学习之路--Java注解专题