使用mina做了乙個webgame的聊天服，已上線幾個月了，鴨梨相當的小，以此文記錄經驗一二。
與前端flash使用協議amf3。
一、壓力測試與修改（cpu*2+memory*4）
1、記憶體增長迅速，cpu占用偏高
原因：廣播的同一條訊息都進行了amf3-object->buffer的編碼
改進：一次編碼，通過buffer進行複製
2、too many open files
原因：開啟檔案描述符號太多，超過系統預設限制，預設open files (-n) 1024
修改系統設定ulimit -n 65535
3、小機械人client最多開到440左右
原因：windows預設埠1024-5000，小機械人使用mina寫的，clienttcpportnum=(nioacceptor.selector*1+nioprocessor.selector*1(cpu*2+1))*2+clientport=9
修改系統設定regedit->[hkey_local_machine /system /currentcontrolset /services /tcpip /parameters] ->maxuserport=65534
4、系統瓶頸：（全廣播）200client*（250message*1second）=50000或者2000client*（25message*1second）
原因：網絡卡write到瓶頸（100m網絡卡4-8m/s），訊息在write後積累，記憶體迅速吃盡，cpu滿負荷。（1條訊息（200k）=heapbytebuffer*1+defaultwritefuture*1+defaultwriterequest*1+encodewriterequest*1+messagewriterequest*1=5）
修改：引入訊息佇列控制傳送模式
二、訊息立即傳送模式與佇列控制傳送模式自由切換
任何系統都有瓶頸，尤其是硬體條件有限的情況下。如何在有限的硬體條件下既保證系統的吞吐量及一定的響應能力，又保證系統的健壯性和穩定性，不至於系統因為瓶頸（系統負載執行高峰期）而崩潰，的確讓人深思。
最後我決定使用優先順序佇列控制訊息的傳送時間及頻率，在極端情況下，丟棄優先順序較低的訊息。
1、使用開關變數控制兩種傳送模式，預設情況下使用立即傳送模式；
2、開啟一定時執行緒監測系統執行狀況，包括積累訊息數、記憶體使用情況、cpu（由於cpu監測耗時比較大，後來去掉了）、佇列中訊息數等；
3、根據系統執行狀況以及硬體情況（cpu+memory+nic）進行兩種模式的自由切換；
4、訊息佇列根據訊息業務邏輯，如使用者聊天資訊、小公告資訊、系統公告等進行優先順序劃分。
就到這裡了，該吃中飯了。
MINA 實現聊天功能
原文同步至 在 mina 快速入門 一文中，我們介紹了如何利用 mina 快速構建乙個 time server 時間伺服器 在 netty 實現聊天功能 一文，我們也介紹了如何用 netty 實現聊天功能。由於 mina 和 netty 是同乙個作者，架構類似，如果你掌握其中乙個，學習另外乙個也不是...
webgame的檔案儲存方案
對於網遊的檔案型別，按照載入來區分的話可以分為這幾種 因為單佇列載入的話在每個單元檔案載入完成之後會有乙個重新建立新的連線的過程 我把它叫做間隙時間 時間。按需檔案 按需載入，隨時需要隨時載入，使用完後徹底銷毀。該類檔案處理起來比較有意思。畢竟按需也有個輕重緩急，等待的時間也 不盡相同，所以在處理上...
mina的簡單例子
簡單例子 客戶端 建立客戶端聯結器.niosocketconnector connector new niosocketconnector connector.getfilterchain addlast logger new loggingfilter 設定編碼過濾器 connector.getf...