日志优化  

  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

登录优化

  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处理消息量最大一类。如下图
差不多是消息发送的10倍左右，虽然ping包处理很简单，耗时很短，但量大了，还是需要考虑优化的。我的优化方案就是把对于客户端发的ping包处理移到链接管理器去。
 
 
A->server回执优化

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

 
id序列号生成器
SequenceManager锁的粒度比较大，并发比较高的时候，就经常会锁住。需要重写。