優化C#伺服器的思路和工具的使用

優化伺服器之前, 需要先對問題的規模做合理的預估, 然後對關鍵的資料做取樣, 做對比, 看和自己的預估是否一致, 誤差大在什麼地方, 是預估的不對, 還是系統實現有問題.

策劃對彩虹聯萌伺服器的要求是3000到5000人線上.

大概的估算

玩了玩遊戲, 在前期任務的流程中, 客戶端對伺服器發生的有效請求數, 實際上是比較少的. 跑路, 點選NPC, 打怪等等, 每一個狀態變化中間需要的時間實際上是比較長的. 所以一秒的請求數應該是在0.5~1.0qps左右.

戰鬥因為是無目標的ARPG, 一點砍瓜切菜的感覺, 輸入大概在1.0~2.0qps, 輸出就比較高了, 目測係數有5.0~10.0

移動和普通的MMOG差別不是很大, 只是如果用鍵盤操作的話, 狀態變化會非常頻繁; 如果是手機的話, 應該在1.0qps左右, 應該就夠了. 唯一需要處理的就是廣播係數, 周圍的玩家越多, 需要廣播的包就越多. 彩虹聯萌一個場景大概有40~50人. 目測係數有10.0左右.

還有DB IO, 也需要估算, 因為單次操作比較耗時. 戰鬥過程中大概率是不需要訪問DB的, 移動也是, 只有普通的任務和養成系統對DB寫依賴比較高; 然後玩家登陸過程中, 因為遊戲內有大量的系統, 可能需要10次load操作. 所以按照以往的經驗, 卡牌型別的遊戲1.0~2.0

採集資料

最開始處理的MongoDB的讀寫資料取樣. 按照我們的估算, load一個玩家需要10個DB操作, 一個玩家線上大概只需要0.5~1.0個DB操作. 但是我們用機器人去跑, 發現處理MongoDB讀寫的佇列經常因為過大, 進而系統OOM.

所以, 對已經完成DB操作, 和正在佇列中的DB操作進行統計分析, 需要統計的資料:

• 型別(簡單標註一下自己是哪個系統的)

• 檔案, 行數(進行準確的追蹤)

  C#有CallerLineNumber, CallerFilePath, 可以方便在編譯時期獲取類似於C/C++的__FILE__

  , __LINE__.

下來採集的是客戶端的輸入, 和傳送給客戶端的返回.

還有一種採集, 就是記憶體快照, 可以通過dotMemory來搞, 直接用VS獲取記憶體快照最後會發現看不清楚. dotMemory在這方面做得不錯.

處理思路

我在計算機程式設計藝術第一卷這本書裡面學到一個東西, 就是時間複雜度和係數. 我們在一般的資料結構或者演算法書裡面只會看到時間複雜度的大概分析, 不會告訴你準確的公式是什麼樣子的.

然而, 我們遊戲裡面需要處理的線上玩家數量所呈現出來的公式, 應該是一次函式: