日志优化
- 默认是 用info 级别,最好不用openfire原生的打日志方式。
- 离线消息用存储不打回方式,不要用打回方式 xmpp.offline.type=store_and_drop
- ConnectionHandler 收到异常,关闭链接的异常日志,用debug级别
- 会有很多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
登录优化
- 用最简单的ssl验证方式,也就是plain 用base64编码 (replace into ofProperty values ("sasl.mechs","PLAIN");)
- 不用安全传输,也就是关掉tls(replace into ofProperty values ("xmpp.client.tls.policy","disabled");)
- xmpp登录流程 有11步包交互,非常复杂和繁琐。可以简化登录流程。运用快速登录,现已经简化到4步,只发stream包和auth包。
- 重写AuthProvider,返回一定要快
离线消息
离线消息默认是用db存储,并且可以设定策略限制每个用户的存储空间。在移到网络下,会经常出现对方不在线,需要存离线的情况,并且每次登录都需要取离线,所以是一个频繁和耗时操作。
- 离线改用缓存存储
- 设置离线消息用存储不打回方式,会少一次网络通信(通知发送方)
链接管理器
链接管理器的运用,可以极大缓解openfire的链接压力。如果直连openfire,每个链接会占有一个文件句柄,每个socket会分配读写缓冲区。会占用大量内存资源。做过测试,当同时在线达到1W,
NIOConnection 将会占用3G多内存。是openfire占用内存最多的。如果用链接管理器,openfire只需要关注业务处理,不需要处理链接建立,释放,最重要的是,只需要维护几十个与链接管理器建立的长链接。当然官方的提供的链接管理器,版本非常老,网络性能低下(链接管理器与openfire之间的通信竟然是直接用的socket,流式处理)。
1台openfire前面可以放多个链接管理器。
- 链接管理器与openfire之间通信方式改用mina。
- 链接管理器与openfire通信本身线程池优化,直接用mina提供的IoProcesser线程池
反空闲优化
设置idletime,防止空闲链接占用资源。openfire提供了好几种方式
1. 客户端主动发pingiq包,服务器会回包
2. 服务端主动发ping包,客户端会回包
3. 运用mina本身提供的keep-alive机制
线程池优化
线程池优化的目的,是使系统使用较少的线程去高效的完成工作。具体分析需要用jstack来分析每一个线程。一般来讲openfire维护几百个线程(包括插件占用的)是比较正常的。
- 1~2个SocketAcceptor线程来处理建立链接,
- IoAcceptor用于监听客户端的连接,每监听一个端口建立一个线程
- xmpp.processor.count=48 用48个线程处理SocketAcceptorIoProcessor,用来IO处理。
- xmpp.processor.threads.standard=64 xmpp.multiplex.processing.threads =64 用来做业务处理,也就是filter处理的过程
- openfire默认是用cpu核数个线程来处理epoll,如果cpu个数比较过多的话,可以减少线程数到8个,可用new NioSocketAcceptor( executor,processorCount );
网络参数优化
-
net.ipv4.neigh.default.gc_stale_time = 120net.ipv4.conf.all.rp_filter = 0net.ipv4.conf.default.rp_filter = 0 //lvs内网通信需要net.ipv4.conf.default.arp_announce = 2net.ipv4.conf.all.arp_announce = 2net.ipv4.tcp_max_tw_buckets = 5000net.ipv4.tcp_syncookies = 1 //启用syn cookiesnet.ipv4.tcp_max_syn_backlog = 8096 //同时,并发建立的链接不能及时处理的放到队列的上限net.ipv4.tcp_synack_retries = 2 //syn ack没有收到,最多做2次重试net.ipv6.conf.all.disable_ipv6 = 1net.ipv6.conf.default.disable_ipv6 = 1net.ipv6.conf.lo.disable_ipv6 = 1net.ipv4.conf.lo.arp_announce = 2net.ipv4.conf.eth0.rp_filter = 0net.ipv4.conf.eth1.rp_filter = 0net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_tw_recycle = 1net.ipv4.tcp_fin_timeout = 10 //对于进入fin状态的,关掉链接的超时时间net.ipv4.ip_local_port_range = 1024 65000net.ipv4.tcp_rmem = 4096 16380 4194304 //读缓冲区(tcp是双工通道,读写通道是分离的)net.ipv4.tcp_wmem = 4096 16380 4194304 //写缓冲区net.ipv4.tcp_mem = 678558 1004745 1457116 //总的内存vm.overcommit_memory = 1xmpp.socket.backlog=8096xmpp.socket.buffer.receive=-1(表示用系统设置)xmpp.socket.buffer.send=-1(表示用系统设置)xmpp.socket.linger=-1是否运用优雅关闭xmpp.socket.tcp-nodelay= true是否用Nagle算法vm.swappiness = 0net.ipv4.neigh.default.gc_stale_time=120net.ipv4.conf.all.rp_filter=0net.ipv4.conf.default.rp_filter=0net.ipv4.conf.default.arp_announce = 2net.ipv4.conf.all.arp_announce=2net.ipv4.tcp_max_tw_buckets = 5000net.ipv4.tcp_syncookies = 1net.ipv4.tcp_max_syn_backlog = 8192net.ipv4.tcp_synack_retries = 2net.ipv6.conf.all.disable_ipv6 = 1net.ipv6.conf.default.disable_ipv6 = 1net.ipv6.conf.lo.disable_ipv6 = 1net.ipv4.conf.lo.arp_announce=2net.ipv4.conf.eth0.rp_filter = 0net.core.rmem_default = 256960net.core.rmem_max = 513920net.core.wmem_default = 256960net.core.wmem_max = 513920net.core.netdev_max_backlog = 2000net.core.somaxconn = 8192net.core.optmem_max = 81920net.ipv4.tcp_mem = 131072 262144 624288net.ipv4.tcp_rmem = 8760 256960 6088000net.ipv4.tcp_wmem = 8760 256960 6088000net.ipv4.tcp_keepalive_time = 1800net.ipv4.tcp_keepalive_intvl = 30net.ipv4.tcp_keepalive_probes = 3net.ipv4.tcp_sack = 1net.ipv4.tcp_fack = 1net.ipv4.tcp_timestamps = 0net.ipv4.tcp_window_scaling = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_tw_recycle = 0net.ipv4.tcp_fin_timeout = 30net.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锁的粒度比较大,并发比较高的时候,就经常会锁住。需要重写。