作者：Oliver，騰訊服務器性能測試團隊產品經理。
特別鳴謝:騰訊高級測試工程師 jinni，leo的干貨內容。
WeTest導讀
大量用戶登錄游戲產生的“洪荒之力”往往會對游戲服務器產生巨大的壓力，游戲上線之前對服務器的承載能力做測試是必須要做的事。本文從騰訊游戲之前服務器性能測試的經歷出發，對服務器性能測試的原理、指標和方法進行了介紹，并介紹了內部目前流行的一些工具和使用技巧。在四年磨一劍的奧運會，要想成功，必須頂住壓力，在0.13秒錯失400米自由泳金牌之后，孫楊在200米自由泳比賽中后來居上，奪回冠軍。
而這次奧運會人們也發現，洪荒之力的力量是無法預估的，傅園慧靠著自己的“洪荒之力”，反復刷新自己的最好成績。
那么，同樣也是多年磨一劍，游戲開發者精心制作的游戲在面對大量用戶的“洪荒之力”時，服務器應該怎樣頂住壓力，高效運轉？
先來看看用戶的洪荒之力能產生什么樣的后果？
1、面對開服壓力，服務器宕機。
版本上線之后，新的服務器開放或者服務器更新，面對大量玩家的涌入，如果服務器的性能不好，就會發生登錄失敗的問題。
2、運營期壓力，玩家體驗損失。
服務器的一個外網活動，比如副本雙倍掉落，可能就會造成玩家在某個場景堆積，此時副本玩家就會比平時高很多，對于服務器而言副本這個業務請求會產生比平常高很多的壓力，就極容易引發相關的性能問題。
據數據公司預測，獲得蘋果推薦的價值相當于200萬美元(1200萬元)左右的推廣費用。法國工作室Ankama Games研發的游戲Tactile Wars拿到了蘋果50多個國家(幾乎是所有上線的地區)的首頁‘最佳新游戲’推薦，而且曾一度達到了美國iPhone免費榜第二名，日均下載量突破25萬，而一個月后該游戲在美國的下載排名已經降到了475，并且有持續下滑的趨勢。歸根結底是因為開發商沒有應對大量玩家涌入服務器的準備，服務器卡死、宕機，閃退讓玩家失望選擇離開。在這之后Ankama花了兩個月的時候才優化服務器逐步挽回了局面。
騰訊游戲下的游戲測試團隊WeTest曾經接入過一款代理游戲，有百萬級的在線人數預估，當時進行了服務器性能測試，測試結果是當時對方的服務器只能承受1500人的同時在線，如果一套服務器只能承載1500個用戶，該游戲要上線需要多少服務器？需要1000套，這無疑是一個巨大的浪費。
面對用戶的“洪荒之力”，慘痛的經歷一次次的發生，“外網問題無小事”，游戲發行、渠道對服務器承壓情況越來越重視，很多都會要求CP提供服務器性能測試報告作為憑據。
然而目前市場上還沒有針對游戲的服務器性能檢測工具，無論是開源還是商業軟件都不能很好的滿足游戲的專項測試需求，與此同時受限于開發周期短以及人力的問題，中小型CP往往采取編寫模擬機器人進行簡單的壓測，測試的覆蓋面窄，無法保證并發請求，造成潛伏的問題遺漏到線上。
同樣是百萬級的游戲，有的公司需要上千臺服務器，而有的公司只要幾百臺服務器，巨大的服務器采購運維成本差異皆因各家公司做服務器性能測試乃至性能調優的能力參差不齊。
那么問題就來了，服務器性能測試是什么？要怎么做才最有效呢？
什么是服務器性能測試？
提到服務器性能測試，不能不提到很多術語。為了讓大家更容易理解，舉個生活中的例子：
你中午去“海底撈”吃飯。我們可以把“海底撈”這個酒樓看成一個被測系統。
你去吃飯，就是對這個被測系統發起請求，對這個系統造成了一定的負載。你帶去的人越多，那么這個餐館就越繁忙，可以說餐館承受的負載就越大。
你開始點菜。這個時候你隔壁桌的人也開始點菜。那么你們兩個對這個系統產生了并發的請求。同時，其他桌有的在吃菜，有的在等菜，這些都是并發進行的事務。一個完整的吃飯事務可以定義成包括：點菜，下單，上菜，買單四個步驟。對于一個C/S的系統來說，可以對應于：建立連接，發送請求，接受應答，斷開連接。
影響一個餐館生意好壞的一個重要原因是上菜速度。上菜速度體現在兩個方面：
1.一個顧客請求的處理耗時，從下單到上菜中間等待的時間，我們稱之為響應時間。
2.這個餐館同時為多名顧客上菜的頻率，我們稱之為吞吐量。
很多因素會影響上菜速度，比如服務員的個數，廚師的個數。對于一個C/S的系統，服務員相當于是接入層，廚師相當于是后臺服務。假如服務員太少，下單很慢，后面的廚師都閑著，那么上菜速度也快不了；假如服務員夠多，下單足夠快，但是廚師太少，下的單來不及做，同樣上菜速度也很慢；如果服務員很多，廚師也很多，但是來的客人很少，那么大部分的服務員和廚師都閑著，資源全部浪費掉了。因此，接入層和后臺服務進程個數、以及資源配比，都是需要根據實際情況進行調優的。
來多少顧客，這是酒樓自己無法控制的，但是酒樓的上菜速度、餐位多少都會制約客流量。一定有一個峰值客流量，當來的客人超過了這個峰值，那么這些客人就會等位，或者是上菜速度超慢讓客人無法容忍。容量測試就是通過工具模擬足夠多的顧客來吃飯的事務，希望找到這樣一個客流量對酒樓產生一定的負載，這個時候酒樓既能接待最多的客戶同時也能保證最短的等待時間。更多的，還可以對這個酒樓人員配置和餐位設置等進行調優，以期達到一個最理想的資源利用率和效率。
客流量跟進來的客人多少有關，也跟餐館的接待能力有關。單方面增加來就餐的顧客，遭到投訴的可能性就越大，上錯菜的可能性也越大。性能測試的核心概念主要包括兩部分：正確的測試方法，正確的評價性能的指標。測試方法會告訴你用什么樣的套路去執行測試；性能指標是告訴你如何用數值來描述你的測試對象的性能。
常用的性能指標
在介紹測試方法之前，先來了解一下關于服務器性能測試的一些指標含義。
【吞吐量】 固定時間間隔內的處理完畢事務個數。通常是1秒內處理完畢的請求個數，單位：事務/秒（tps）。
【平均吞吐量】一段時間內吞吐量的平均值。無法體現吞吐量的瞬間變化。
【峰值吞吐量】一段時間內吞吐量的最大值。是用來評估系統容量的重要指標之一。
【最低吞吐量】一段時間內吞吐量的最小值。如果最小值接近0，說明系統有“卡”的現象。
【70%的吞吐量集中區間】通過統計15%和85%的吞吐量邊界值，計算出70%的吞吐量集中區間。區間越集中，吞吐量越穩定。
【響應時間】一次事務的處理時間。通常指從一個請求發出，到服務器進行處理后返回，再到接收完畢應答數據的時間間隔，單位：毫秒。
【平均響應時間】 一段時間內響應時間的平均值。無法體現響應時間的波動情況。
【中間響應時間】一段時間內響應時間的中間值，50%響應時間，有一半的服務器響應時間低于該值而另一半高于該值。
【90%響應時間】一段時間內90%的事務響應時間比此數值要小。反應總體響應速度，和高于該值的10%超時率。是用來評估系統容量的重要指標之一。
【最小響應時間】響應時間的最小值。反映服務最快處理能力。
【最大響應時間】響應時間的最大值。反映服務器最慢處理能力。
【CPU占用率】1-CPU空閑率，表示CPU被使用情況，反映了系統資源利用情況。常用的測試方法-------關于服務器性能測試，目前常用的測試方法有這些：
一、現網數據預估
現網數據預估是根據壓力測試過程中的部分數據，對未來大量用戶訪問的情況機型預估。途中的橫軸代表現網吞吐量，縱軸代表CPU壓力。圖中綠色的部分代表當前的服務器壓力，當收集一段時間數據之后，可以模擬一條曲線。假設對服務器的上線成本預估是80%，可以通過曲線擬合的方式推測出現網的能力是多少，也從而推斷出最大上限是多少。缺點：通常游戲服務器都是比較復雜的，這種方式只適合簡單的服務器擬合，復雜服務器數據就不太準確。
二、真人壓測
真人壓測就是通過邀請一定數量的真實用戶來玩游戲，從而對服務器達到一個測試效果。這種方式他最大特點在于用戶的行為相對是最真實的，因為用戶的使用完全不會受到限制，和線上一個真實用戶一樣。目前游戲上線過程中的“封測”，就可以被認為是一種真人壓測，可以幫助開發者發現一些性能問題。
但是這種方式也存在著弊端。
1、 暴露出的性能問題有限
許多經過封測的游戲到上線還會產生問題，原因之一就是封測人數通常還是太少，雖然有幾百或者幾千用戶在玩，但是并發并不夠，不足以暴露服務端性能問題；
2、 不適合調優
服務器性能測試不光需要暴露服務器的問題，暴露問題之后還需要不斷的回歸調優，但是真人是無法完全重復這些行為方式的。
三、接口測試
服務器方面的接口測試與傳統意義上的接口測試略有不同，當開發人員需要對一套服務器進行評估，但是又時間不足的情況下，我們可以考慮選擇一些具有代表性的功能，以及一些高風險功能進行測試，通過以小見大的方式，來評估整套服務器性能。當然這個方法的主要問題就是無法遍歷整個服務器的接口，難以避免一些微小的問題。
四、錄制回放
這里面包含兩部分，“錄制”就是通過抓取數據包的方式，來獲取游戲時的協議，比如用戶登錄游戲時抓取登錄包；“回放”即把這些捕獲的協議重新發送給服務端，這樣理論上就可以通過工具放大協議量級達到性能測試的目的，比如將之前錄制的登入協議擴大1w倍給服務器，這樣就模擬了1w人同時登入的情況。
這個方法存在的問題是，游戲的協議交互非常復雜，如果只是單純的放大數據包，對于服務器是產生不了多大的壓力的。這類方法比較適合固定輸入輸出服務類型的測試。
五、機器人模擬
機器人模擬測試是對以上各種測試做了一個平衡， 通過高還原真實玩家的用戶行為，模擬高并發場景，從而得到類似很多人同時游戲的測試效果。機器人模擬有三個優勢：
1、 高還原游戲玩法，深度模擬真實用戶行為；
2、 并發性不受限制，從1W到10W，壓力能夠自主設置；
3、 可以反復執行，便于性能調優回歸；
4、 實現7乘24小時不斷監控，在開發提交代碼之后，版本在自動編譯之后就跑新的測試，這樣每天都能進行性能監控，在調優方面，完全的進行一個重復性測試，可以不斷的進行回歸和調優。
這個方法的問題就在于機器人模擬需要專人開發，對測試者的開發能力，分析能力都有一個比較高的要求。
說到這里，我們對之前所有的服務器性能測試方法進行了一個總結：
我們可以發現，速度與準確性始終是對立的，如果游戲開發者隊友服務器測試有一個明確的規劃，對服務器壓測有一定的時間預留，機器人模擬的效果是非常好的。
如何實現機器人模擬
那么我們到底是如何來開發一款進行服務器性能測試的機器人呢？整個開發過程主要可以概括為三大步驟，建模， 分析， 開發。
第一步，建模。
建模是什么呢，建模是為了模擬真實玩家行為，分為兩種方法：
1、 探索典型玩家關鍵路徑
通過大量玩家數據的支撐，選擇最多的行為路徑，設計機器人模擬的行為。
2、 通過封測過程中的運營數據，生成專家視圖
這個方法就是通過去測試服中搜集用戶的協議數據，并對這些協議數據進行分析，確定各自是什么行為，把用戶的這些協議數據還原成為用戶行為的操作過程就像是把一塊塊散亂的拼圖重新組織起來一樣。
在這個過程中，最簡單的是按比例組織，通過數據分析，發現用戶登錄，戰斗各自占據多少比例，以這個比例來分配一定的人數進行登錄和戰斗。但是這個方式并不太適合游戲，對于游戲本身來說，一百個人不斷的重復登錄的行為，一百個人同時重復游戲的行為，顯然是不符合邏輯的。那么在分析的過程中，采用概率的方式，是更加貼近一個真實用戶的行為的。當模擬一個真實用戶登錄之后，有一定的可能性會重新登錄，還有一部分可能性就進行戰斗，例如機器人有10%概率重新登入，50%概率進行戰斗。 同時我們還需要考慮對角色身上的裝備數據， Cache的命中，數據庫容量等等，目的是讓機器人更接近真實用戶，更加符合一個真實用戶的行為。
第二步，分析
那么我們會對客戶端進行行為交互和協議分析。一方面，為后續協議開發實現做準備；另外，在登入的過程中，會產生大量的協議，如果沒有對客戶端進行分析，可能只是調用了登錄的協議，從實際的協議交互上來說，一次登錄可能包含了很多其他的協議信息，那這時我們實現登入就不能僅僅是個簡單的登錄協議，可能還包含拉取郵件信息，拉取好友信息等協議，兩者之間對登入的性能差異影響非常大。
第三步，代碼開發
主要包含兩部分：
1）協議的開發，包括協議的實現，協議的解包等；
2） 業務邏輯的組織，主要對上述游戲模型進行實現。
服務器性能測試工具的使用
不過令人遺憾的是，對于游戲開發者的實際情況來說，充足的測試時間并不是每次都可以保證的，而且對于模擬機器人的開發過程本身又是一個很大的投入，對于一些通用場景，如果能夠有通用的平臺代碼可以調用，相信對于游戲開發者是一種極大的解放。
騰訊WeTest的壓力測試團隊根據十多年的內部實踐經驗總結，基于真實業務場景和用戶行為進行壓力測試，推出一套面向游戲業務的綜合性應用性能管理解決方案，目的在于幫助游戲開發者發現服務器端的性能瓶頸，進行針對性的性能調優，降低服務器采購和維護成本，提高用戶留存和轉化率。針對不同的應用場景，可以選擇不同的模式進行操作。
1）簡單模式
對于HTTP協議可以通過簡單的界面配置，在1分鐘內直接發起壓力。
2）高級模式
對于類似游戲的復雜混合場景，可以結合在線代碼開發IDE，實現對任何標準或自定義協議的通信，實現了四個目標：
業務場景模擬?？删幋a解析任意協議，實現復雜業務場景。
發現瓶頸。支持使用場景中復雜的數據傳輸行為，比如“登錄”“查看個人信息”等，更加真實的模擬用戶行為，發現服務器問題；
持續壓力。實現7*24小時一定量級的服務器壓力；
觸達極限。短時間內觸達服務器的壓力上限。
目前騰訊WeTest服務器性能測試已經正式對外開放，點擊鏈接：http://wetest.qq.com/gaps/立即體驗！
