1、禁用原生xmpp搜索，使組織架構、人員數據本地化保存，並使客戶端數據同步服務器，降低原生xmpp搜索的iq消耗，因為搜索是im應用的頻繁操作；
2、禁用roster花名冊、禁用presence包通訊，企業im中的好友概念非常沒必要，使用發布訂閱的方式替代狀態服務，見http://www.cnblogs.com/starcrm/p/5029231.html。並重寫狀態更新的廣播：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，這里很詳細
http://blog.csdn.net/linyu19872008/article/details/24022929?utm_source=tuicool&utm_medium=referral
14、讀讀官方的優化方案：
http://www.igniterealtime.org/support/articles/openfire_optimization.jsp
15、另外，增加消息回執機制，解決of4.0以前的本身機制造成的丟消息風險，不清楚前幾天新發布的of4.0對這個有沒有改進。
歡迎補充。