1、禁用原生xmpp搜索，使组织架构、人员数据本地化保存，并使客户端数据同步服务器，降低原生xmpp搜索的iq消耗，因为搜索是im应用的频繁操作；

2、禁用roster花名册、禁用presence包通讯，企业im中的好友概念非常没必要，使用发布订阅的方式替代状态服务，见。并重写状态更新的广播：PresenceUpdateHandler中的broadcastUpdate方法。

如果想保留好友机制，建议把好友信息本地化保存，不要每次都从服务器拉取了。

3、禁用MUC的Password-Verification特性，它将造成客户端开窗前的大量iq交互。改造Roles、 Affiliations、Disco 、Querying等交互，但muc消息通讯机制可以沿用。

4、头像分离出vcard，在有头像情况下实在是太占流量了，而且openfire的缓存基本都被vcard、roster占了。头像放云里，或者搞头像服务，并且做客户端同步。

5、避免为每一种请求开发一个新iq，设计一个通用的处理iq，统一包装并解析json，简化业务处理。

6、TLS连接使用更快的算法（用ECDHE RSA-2048代替RSA-4096，而不是DHE、RC4）

7、如果使用SCRAM-SHA-1算法，服务器将哈希密码处理 (每次都发同样的salt) ，可以对 SaltedPassword 进行缓存, 将节省处理时间。

8、自动更新管理需要改进，因为openfire设计的客户端下载升级是通过自身的服务器进行，当大量客户端同时下载时一定挂。

9、尝试用redis存储缓存，让of专注于一件事：消息处理。

10、离线信息存储分库，或者用redis存。

11、不要用windows版的of，最大java内存难以大于1300MB，另外linux可更多的tcp连接。在linux下执行ulimit -n 100000设置为10万。

12、保证你重写AuthProvider的验证返回一定要快，你会发现登录时间至少提升1-2秒。

13、将登录验证的9个round trip，减少到3个round trip，这里很详细

14、读读官方的优化方案：

15、另外，增加消息回执机制，解决of4.0以前的本身机制造成的丢消息风险，不清楚前几天新发布的of4.0对这个有没有改进。

欢迎补充。