通過一輪的服務器性能測試，有些心得，總結一下分享給大家，有什么錯誤或者建議，請指出。
針對當前游戲的架構，要開展性能測試，就需要先分析當前架構下，預計會出現哪些性能風險，服務器端和客戶端分開進行分析。
服務器端：內存消耗、Cpu占用、登陸壓力、單服承載、同屏承載、同地圖承載、帶寬
客戶端：流量、幀數(FPS)、內存消耗、Cpu占用、流暢度
一.服務器端
服務器端采用的是多線程，分為邏輯線程和網絡線程，分開分析：
1.邏輯線程：
假設服務器設定每個心跳耗時200毫秒，即1秒5個心跳，這是一個固定值。一個心跳循叫一幀，如果某幀需要處理時間為100毫秒，那么服務器就有50%的空閑時間;再如果某幀需要處理200毫秒，那么該線程的cpu占用則為100%。也就是說，如果服務器一幀需要的處理時間為5秒鐘，那么客戶端發送過來的請求經過處理后收到反饋需要的時間為(5秒+消息在網絡上來回消耗)，即傳說中的服務器卡。
那么，要驗證邏輯線程卡不卡，或者要找出某負載下邏輯線程卡的原因，則需要記錄各種邏輯處理所消耗的時間。目前服務器邏輯消耗主要在玩家和怪物邏輯上，因而需要記錄的數據有怪物數量、總邏輯耗時、怪物邏輯耗時、玩家邏輯耗時和其他邏輯耗時。設計用例時則需要考慮不同負載下和無人空跑時的以上耗時的數據采集。
采集到這些數據后，可以得出邏輯線程cpu占用，怪物耗時占用百分比，玩家耗時占用百分比，并進行分析，如果發現怪物耗時過多，則可以通過增加怪物休眠功能、減少怪物巡邏頻率、減少怪物數量等方式來降低消耗;如果發現玩家耗時過多，則需要分析是哪一塊玩家邏輯導致，必要時可以增加細分的玩家耗時log來獲取數據進行分析。
2.網絡線程：
假設1個角色每秒產生的消息條數為a條，那么X個角色同時在線的話，產生的總消息條數Y大概為：Y=a*x;而每個角色產生的a條消息，又分為需要廣播和不需要廣播的。
需要廣播的消息在處理后放大n倍，如移動消息，處理完畢后需要同步給周圍的角色，如果周圍有m個角色的話，消息條數就由1àm，最極端的情況為消息需要同步給全服角色，消息條數會由1àX;又如私聊消息是一對一，因為不需要廣播，所以處理完畢后就不會使信息量放大;最極端的情況，全服的全部角色產生的消息都是需要全服廣播的，比如全部玩家都在世界頻道喊話，那么產生的消息量為Y=a*X*X。
那么，要驗證網絡線程卡不卡，或者要找出某負載下網絡線程卡的原因，則需要記錄各個消息在一定時間內一定負載下的發起數量、分發數量;網絡線程耗時、各種消息單種的總耗時、耗時均值、峰值;消息是否為同步消息;另外我們還可以記錄當前服務器消息堆積數，以及堆積的消息種類和數量。
通過這些數據，我們可以得出網絡線程cpu占用百分比，同步消息的平均同步次數;全部消息中，同步給全服的消息、同步給周圍的消息、不需要同步的消息占整體消息百分比;
通過這些數據，我們可以哪些消息導致瓶頸，哪些問題導致消息量過大等;通過平均同步次數，可以得出同屏人數瓶頸、同地圖人數瓶頸等;通過不同負載下的數據，還可以得出性能數據趨勢，也就是說可以通過500人數壓力的負載得出的數據，推斷出700、1000人數負載下的性能數據;同時，我們還可以通過采集到的數據，分析哪些消息耗時高，哪些消息數量大。得出以上結論后，就可以有依據有針對性的進行相關優化。
舉例：服務器在300機器人全部世界聊天時，網絡線程耗時過高，消息響應延遲非常嚴重，但是服務器采集到的消息堆積數為0，也就是說無消息堆積。
分析：問題肯定是出在網絡線程，通過代碼分析，發現服務器全部接收了全部消息，所以消息沒有堆積，但是服務器接收了消息后，無法全部快速處理完，所以導致了消息響應延遲嚴重，就像是部門經理把手頭的100個任務全部丟給1個人處理，經理手頭是沒有任務堆積，但是那個手下由于無法快速處理完這些任務，導致任務響應很慢。
進一步分析，發現消息主要耗時分2塊：網絡庫消息的發送和服務器對消息的處理，比例為7:3。
問題找到了，負責網絡庫的研究網絡庫的性能，負責服務器的程序找出對應瓶頸。也可以采用另一種方案，那就是限制全服同步的消息的產生，只不過這個只是一個迫不得已的方案而已
3.接下來分析內存風險，以現在的配置，服務器內存占用的多少不用過多考慮，主要要考慮的是內存泄露，主要通過查看一點壓力下運行一段時間的內存變化情況來檢查
4.服務器帶寬的評估，可以通過記錄每個一段時間內收到和發送給客戶端的數據包大小和數量來計算出每秒的數據量，然后換算出需要的帶寬。bps：byte per second。需要分析的是每秒byte數，現有網絡，1m的帶寬(單位是bit)，帶寬數值跟流量的比例理論上為：流量=帶寬/8，加上損耗，能到達的最大流量大概為100K
5.最后一個登陸壓力，主要是驗證登陸系統對于大量登陸請求的響應情況。當前情況下不用考慮，因為有已經運營的產品在驗證。如果考慮這方面的性能測試的話，應該從一定負載下登陸系統的響應情況來考慮，比如100/500/1000機器人批量賬號驗證、批量創建角色、批量登陸游戲，采集這些數據進行分析。
6.總結，通過前面5個步驟的分析，對于前面提到的服務器端性能風險，都已經覆蓋到了，剩下的就是根據這些分析設計性能測試用例了
二.客戶端：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
