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，這裡很詳細

14、讀讀官方的優化方案：

15、另外，增加訊息回執機制，解決of4.0以前的本身機制造成的丟訊息風險，不清楚前幾天新發布的of4.0對這個有沒有改進。

歡迎補充。