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登錄，實際使用還是需要簡化登錄流程，這點需要客戶端配合。