openfire壓測概述

Openfire采用Java開發，基于XMPP(Jabber)協議，開源的即時通訊服務器。一直以來，對于服務器的支持最大用戶數總是讓人感到疑問，官方甚至還是幾年前的5k。在熟悉了openfire源碼后，我決定花些時間測試一下openfire的極限。經過約1個月左右的測試,總算得到預定目標(3臺服務器,并發50w用戶在線)

測試環境搭建

壓測客戶端無他-tsung，嘗試了windows安裝perl失敗后，使用centOS6.5作為壓測機

壓測服務器,因為集群需要大內存,因而安裝了64位的centos6.7.

所幸這些都可以使用vmware虛擬機,只要裝好一臺,通過簡單copy就能復制出多臺.實際上,一共也就使用了6臺硬件設備.

設備類別 ? ? ? ?臺數 ? ? ? ?系統 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??虛擬機操作系統 ? ? ? ? ? ? ? ?說明

OF服務器 ? ? ? ? 3 ? ? ? ? ??i54570,12G,Win7 ? ? ? ? ? ? ?CentOS6.7 8G ? ? ? ? ? ? ? ??其中一臺運行mysql數據庫

tsung客戶機 ? ?3 ? ? ? ? ??i54570,4G,Win7 ? ? ? ? ? ? ? ??CentOS6.5 1G ? ? ? ? ? ? ? ?虛擬機1G內存,運行3個實例

jvisualvm+mat使用

如果不跑集群,其實openfire還是比較穩定的，單臺4G內存情況下，也有運行到25W同時在線的情況。一旦用了hazelcast，反而不穩定了，出現問題就需要使用工具進行定位，看看哪里堵住了。

運行結果與心得:

0.千萬不要用OpenJdk的虛擬機,官方推薦用CMS進行GC,那就老實點用JDK7.

1.openfire使用mina作為nio底層實現.實測一秒20-25個新連接還算穩定,超過30個就會堵住.(占用大量內存存儲未處理的包-經查,時offlineMessage堵住,tsung去掉發送消息的,就快了)

2.openfire使用hazelcast的緩存機制實現集群。經過實際測試，這貨太消耗內存了，20w連接大概需要4G的內存(包含mina連接需要的內存)，加上還要互為主備的機制，至少還要1.5G才能實現集群的使用。測試至少要8G內存才行,實際使用推薦12G以上.

3.僅僅是壓測同一臺服務器,與同時壓測多臺情況大不相同,后期改進主要集中在數據庫性能.(后期改進點-)

4.Linux內核修改limits.conf和net.nf_conntrack_max參數后性能有所提升。

程序優化點：

1.JVM配置優化：

需要自己修改openfire.sh,增加虛假機參數.(hazelcast插件有推薦配置,修改一下就行)

2.offlineMessageStore+squenceManager優化：

前面說過了，mysql最多支持每秒30個的NextID，實際運行offlineMessage會很多，修改使用redis保存離線消息。

3.hazelcast和openfire優化：

hazelcast本身就很多問題，例如一臺設備內存滿了或者處理超時，那么整個集群就沒響應了。如果還是用hazelcast作為集群的緩存，需要剝離到單獨的設備上去。

openfire用的是java的序列化，內存用的多，效率慢；hazelcast是支持自定義序列化的，經過比較，我用了kryo作為序列化工具，在對ClientSessionInfo，Roster，RosterItem，User這幾個類優化后，內存使用明顯小了很多。

SessionManager 把所有的clientSession都放到hashmap中,當用戶變得非常大量時候，sessionInfoCache的操作必然影響效率。

4.登錄流程簡化：

xmpp的登錄報文交互太多了，雖然tsung使用最簡單的iqauth登錄，實際使用還是需要簡化登錄流程，這點需要客戶端配合。

本文出自http://www.cnblogs.com/imparser/p/5156656.html

總結

以上是生活随笔為你收集整理的openfire java集群_优化openfire服务器,达到单机20万,集群50万的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。