Openfire 性能優化

Openfire  是一個XMPP協議的IM Server。

 

Openfire使用mysql配合它不知所謂幾乎無效的的Cache機制就註定沒法支撐高併發，

因此第一步，將數據庫切換爲比較強一點的MongoDB。

可是MongoDB也是有問題的，在高併發時纔會發現，MongoDB的鎖表十分嚴重，

通過調查發現，MongoDB也比較坑爹，他是使用「全局鎖」的，也就是說，你更新A表的時候，會鎖住B表，數據更新後解鎖。

因此做爲實時查詢數據庫即便是使用MongoDB的master/slave模式依然不能勝任。

 

增長解決方案，緩存層，使用redis做爲MongoDB的數據緩存，在訪問時數據時，首先進入Cache層訪問redis，若是沒有，再去訪問MongoDB，而後再回頭填充Redis。

OK，數據源解決了，接下來確認須要在什麼地方切入。

 

1，首先是將用戶信息數據切換到MongoDB中。並中止Openfire本身的Roster服務，在管理控制檯設置 xmpp.client.roster.active = false

2，AuthProvider，這裏是登錄模塊，能夠繼承接口重寫一個屬於本身的Provider。

重寫authenticate方法，將登錄驗證請求交給cache層。

3，離線信息的存儲在以後也會成爲負擔，那麼繼承OfflineMessageStore類，重寫屬於本身的離線信息策略，將離線信息保存到Redis中。

4，重寫狀態更新的廣播：PresenceUpdateHandler中的broadcastUpdate方法。

 

好了，這時候Openfire已經被修改的面目全非，可是效率已經不可同日而語了。

這時候還有一個問題，就是Openfire沒有消息保障機制，也就是說，網絡不穩定的時候，客戶端異常斷線，信息就會發送到空氣中，

須要再發送信息的時候實現「握手機制」來保障信息的可靠性。不細說了，本身百度。

 

這時候Openfire的在線用戶能夠飈到6W無壓力，可是死活上不去了，又被限制了。

在error.log中會發現相似 「open files too larger」 一類的錯誤，這些是linux系統參數：最大文件打開數。

在linux下執行ulimit -a就能觀察最大的文件打開數，執行ulimit -n 350000設置爲35萬，而後kill掉openfire退出控制檯，從新鏈接控制檯使其生效，從新啓動Openfire。

好吧，這時候用戶量能夠飆6W以上了。

XMPP服務器的測試工具，比較簡單的可使用tsung來實現，簡單的配置，模擬成千上萬的用戶登錄，而且能夠模擬HTTP等其餘請求。

 

接下來就是單臺服務器容量的問題了，咱們服務器是Dell R710， 64G內存 16核CPU，15000轉硬盤。

服務器在這種架構下在線用戶數據在29W左右，幾乎已是單臺Openfire封頂了。

開始考慮集羣，不過Openfire的幾種集羣都測試過，效果不理想，有一個神馬war包的插件，弄上去時好時壞，放棄。

還有一個oracle的集羣插件，不過在高壓下多臺Openfire直接脫離集羣，本身玩本身的了。。。日。

 

若是到了十萬二十萬左右的在線用戶級別，就放棄掉Openfire，能夠嘗試使用tigase試試，或者和咱們同樣，本身寫通信服務器。

 

 

 如下內容參考文章：http://blog.csdn.net/jinzhencs/article/details/50404574

其餘設置以及優化

插件

• Subscription插件：自動贊成好友請求，添加插件後在服務器設置最下面設置方式。

服務器設置

• 把沒用的一些設置關掉，例如HTTP綁定等等

優化

• 修改打開最大文件數目：ulimit –n 65535
• 設置服務器緩存大小，系統屬性加入：

// 注意不能有空格，特別是 size後面
// -1表明無窮大 100000000便是95M
ClientSessionInfoCache：     cache.ClientSessionInfoCache.size
Roster：                     cache.username2roster.size
user：                       cache.userCache.size
group：                      cache.group.size
groupMeta：                  cache.groupMeta.size
offline message：            cache.offlinemessage.size
offlinePresence：            cache.offlinePresence.size
Last Activity Cache：        cache.lastActivity.size
VCard：                      cache.VCard.size
// 以上都是高壓下容易飄紅的

 

 

 

 

 

 

 

 

 要重啓openfire服務才能更新過來哦

 

 

 

將來須要優化的幾個點：

1.加大服務器內存 20G變成150G 2.以前源碼修改的是3.10.2,以後把新版本的源碼下載下來從新修改,然後打包部署. 以解決3.10.2遺留的BUG（如今4.0beta版本出來了,可能過段時間會開源,改了不少bug） 3.根據需求定製openfire，即去除無用的組件,出去無用的消耗資源的一些cache或hashMap,變量之類 4.移出session,把session存入到redis中。 5.除了session,其餘的不少cache(服務器緩存)所有移入redis。

 openfire不使用mysql,使用redis做爲數據庫存儲數據,再作個mysql持久化及主從就好了。

論壇有牛人說過:openfire使用了它那不知所謂的cache(其實就是HashMap),就註定沒法支撐數十萬鏈接。 
（強哥說了:HashMap存儲超過幾萬後,會有問題，好像是jdk自帶的問題）


另一個最重要的優化的方面，就是保證連上服務器的是 有用 的用戶。
譬如咱們服務器以前連了10W，可是其實真正用戶綁定並使用XX系統的只有1W，可是10W個客戶端倒是連着的。 （舉例子，以前咱們的系統就比如進入淘寶後臺自動登陸旺旺，那麼進淘寶多少人就有多少人登陸了旺旺，可是其實真正使用旺旺的只有十分之一甚至更少，咱們只須要讓用戶在須要旺旺對話的時候才鏈接服務器的話，那麼瞬間服務器壓力能減小 90% 這是比任何優化方案都有效的解決方法。是從業務自己去思考並優化，這個須要集思廣益。）