頁遊伺服器壓力測試方案

目的：

　　為保證單個伺服器的線上玩家數量，在專案的初期，應該通過壓力測試來預測線上玩家的上限！

 

工程說明：

　　我們本著實驗主義，認為一切理論皆是假設，而實踐實驗是檢驗真理的唯一標準！頁遊伺服器取自大型端遊單伺服器\單地圖伺服器的設計；用單執行緒去處理所有的邏輯，IO，資料庫,檔案操作各有負責的執行緒，執行緒之間通訊用非同步訊息佇列！  這樣方案的優勢在於，化解了多程式部署上的問題和運營成本，吸取了多執行緒的優勢，而不必在編寫邏輯的時候考慮多執行緒，在一定程度上解放程式設計師，即加快開發進度，以適應競爭日益激烈的頁遊！

 

測試指標：

　　1： 網路庫的吞吐量！

　　2： 網路延遲                           

　　3： 記憶體使用狀況                  

　　4： 最高玩家線上

 

方案1：

　　採用PINGPONG測試方案，客戶端向伺服器傳送訊息包，服務端接收到客戶端的訊息包，將訊息報原封不動的返回給客戶端，客戶端接收到訊息包，再次傳送給伺服器，如此往復！

方案2：

　　在方案1的基礎之上，每一個客戶端傳送的訊息包，攜帶當前時間，當客戶端收到服務端的返回時，用當前時間減去訊息包所攜帶的時間，就是網路延遲

方案3：

　　記憶體的使用狀況，還是通過作業系統的工具來，比如top等！

方案4：

　　外網環境模擬：

　　在開服期間，頁遊平臺向伺服器不斷的匯入玩家；匯入使用者的期間，是單服壓力最大階段，最高線上預計在3k左右；這3k的人分佈在三個地圖之上，地圖較大，螢幕內大概也就10個左右的玩家。我們做很多機器人來模擬大量玩家。在開服幾天，每個玩家的視野大概也就是一螢幕的地圖，每個螢幕上的地圖大概分散著10（N個，可調整）個左右的玩家。這十個玩家，每走動一次，都要將自己的最新狀態廣播給周圍的這十個玩家。我們將地圖分散開來，假設每一張地圖上面就只有十個玩家，我們開啟200個這樣的地圖，這樣就是2k的人線上，每一個機器人，每秒向後端做3(N，可以調整)個請求，後端將這樣一個請求廣播給給圖上其他的9個玩家並且返回給機器人自己！這樣就模擬了2k線上的情況；如果我們開啟300個地圖，那麼也就是3k線上。以此類推！

　　在這樣的模擬環境中，我們要檢測一些資料，

     1：網路延遲，在100ms左右，可以容忍；

     2：伺服器每秒處理的訊息數，

     3：記憶體狀況監測，檢視是否有記憶體洩露問題！

     4：調整每個地圖上的玩家個數，和開啟的地圖數目

     5：調整機器人每秒的請求數

客戶端技術：

    起初我的方案是用執行緒去去模擬玩家機器人，隨後棄之~，其實只要用socket就好，用epoll去管理N個socket(機器人)的傳送和接受資料！傳送一般為定時傳送，接受則需要epoll的機制。故壓力測試的客戶端，可以和服務端公用一個底層！