转 Openfire 性能优化
Openfire 性能優(yōu)化
2012年05月28日 星期一 15:58
http://blog.csdn.net/smm11230704/article/details/7468010
?
Openfire? 是一個XMPP協(xié)議的IM Server。
基于MINA的java nio服務(wù)器。
一般就是使用mysql來作為數(shù)據(jù)庫，保存配置配置信息、離線信息、用戶數(shù)據(jù)。
官網(wǎng)的數(shù)據(jù)是支持5000人同時在線，使用connectionManager可以實(shí)現(xiàn)支持3.3萬人在線。
這數(shù)據(jù)一點(diǎn)都不漂亮，只能作為一個類似騰訊通的局域網(wǎng)聊天工具使用。
首先說點(diǎn)題外話，我測試用connectionManager。
這是一個openfire提供的連接管理器，作用其實(shí)是數(shù)據(jù)整流。
源碼里是通過阻塞式多線程將信息通過特定端口與openfire提交數(shù)據(jù)。
測試之后的結(jié)果，這玩意嚴(yán)重影響效率，放棄，我們的目標(biāo)不只是3.3萬人。
Openfire使用mysql配合它不知所謂幾乎無效的的Cache機(jī)制就注定無法支撐高并發(fā)，
所以第一步，將數(shù)據(jù)庫切換為比較強(qiáng)一點(diǎn)的MongoDB。
但是MongoDB也是有問題的，在高并發(fā)時才會發(fā)現(xiàn)，MongoDB的鎖表十分嚴(yán)重，
經(jīng)過調(diào)查發(fā)現(xiàn)，MongoDB也比較坑爹，他是使用“全局鎖”的，也就是說，你更新A表的時候，會鎖住B表，數(shù)據(jù)更新后解鎖。
所以作為實(shí)時查詢數(shù)據(jù)庫即使是使用MongoDB的master/slave模式依然不能勝任。
增加解決方案，緩存層，使用redis作為MongoDB的數(shù)據(jù)緩存，在訪問時數(shù)據(jù)時，首先進(jìn)入Cache層訪問redis，如果沒有，再去訪問MongoDB，然后再回頭填充Redis。
OK，數(shù)據(jù)源解決了，接下來確認(rèn)需要在什么地方切入。
1，首先是將用戶信息數(shù)據(jù)切換到MongoDB中。并停止Openfire自己的Roster服務(wù)，在管理控制臺設(shè)置 xmpp.client.roster.active = false
2，AuthProvider，這里是登陸模塊，可以繼承接口重寫一個屬于自己的Provider。
重寫authenticate方法，將登陸驗(yàn)證請求交給cache層。
3，離線信息的存儲在之后也會成為負(fù)擔(dān)，那么繼承OfflineMessageStore類，重寫屬于自己的離線信息策略，將離線信息保存到Redis中。
4，重寫狀態(tài)更新的廣播：PresenceUpdateHandler中的broadcastUpdate方法。
好了，這時候Openfire已經(jīng)被修改的面目全非，但是效率已經(jīng)不可同日而語了。
這時候還有一個問題，就是Openfire沒有消息保障機(jī)制，也就是說，網(wǎng)絡(luò)不穩(wěn)定的時候，客戶端異常斷線，信息就會發(fā)送到空氣中，
需要再發(fā)送信息的時候?qū)崿F(xiàn)“握手機(jī)制”來保障信息的可靠性。不細(xì)說了，自己百度。
這時候Openfire的在線用戶可以飚到6W無壓力，但是死活上不去了，又被限制了。
在error.log中會發(fā)現(xiàn)類似 “open files too larger” 一類的錯誤，這些是linux系統(tǒng)參數(shù)：最大文件打開數(shù)。
在linux下執(zhí)行ulimit -a就能觀察最大的文件打開數(shù)，執(zhí)行ulimit -n 350000設(shè)置為35萬，然后kill掉openfire退出控制臺，重新連接控制臺使其生效，重新啟動Openfire。
好吧，這時候用戶量可以飆6W以上了。
XMPP服務(wù)器的測試工具，比較簡單的可以使用tsung來實(shí)現(xiàn)，簡單的配置，模擬成千上萬的用戶登陸，并且可以模擬HTTP等其他請求。
接下來就是單臺服務(wù)器容量的問題了，我們服務(wù)器是Dell R710， 64G內(nèi)存 16核CPU，15000轉(zhuǎn)硬盤。
服務(wù)器在這種架構(gòu)下在線用戶數(shù)據(jù)在29W左右，幾乎已經(jīng)是單臺Openfire封頂了。
開始考慮集群，不過Openfire的幾種集群都測試過，效果不理想，有一個神馬war包的插件，弄上去時好時壞，放棄。
還有一個oracle的集群插件，不過在高壓下多臺Openfire直接脫離集群，自己玩自己的了。。。日。
如果到了十萬二十萬左右的在線用戶級別，就放棄掉Openfire，可以嘗試使用tigase試試，盡管我沒試過，不過看過源碼，覺得還是比較可靠。
或者和我們一樣，自己寫通訊服務(wù)器。
轉(zhuǎn)載于:https://my.oschina.net/vdroid/blog/171386
總結(jié)
以上是生活随笔為你收集整理的转 Openfire 性能优化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 快速排序算法-php实现
- 下一篇： [Winform]一个简单的账户管理工具