如何合理的評估上線服務器數量

1、性能指標

 

咱們知道服務器，有 CPU、內存、IO、網絡等一系列指標，除了這些系統級的，還有些針對各個語言本身的性能參數，而一個服務器的吞度量與請求對CPU的消耗、外部接口、IO等等緊密關聯的 ,面對這麼多繁雜的參數咱們如何有效而快速的利用,如何評估這些性能參數信息? 下面我以遊戲服務器來爲例說一下咱們主要關注點。

 

咱們主要關注如下3個點:

併發數:併發請求數

響應時間:平均響應時間

TPS:每秒鐘處理事務數量

TPS =併發數/響應時間

 

經過上面咱們看到，TPS但是反映一個服務器的吞吐量的綜合值，他是咱們評估服務器性能的一個重要參考，經過tps，咱們能夠知道單臺服務器的最大請求能夠處理多少，pcu(同時在線人數)是多少 ，以及配合其餘性能參數，咱們還能夠定位到服務器的性能瓶頸,因此咱們預估服務器的性能的時候，TPS是一個關鍵的參考值。

 

---

 

2、上線前的測試流程

 

 一、測試模型設計

     這一部分，也能夠叫測試目的的肯定，不一樣測試目的，對測試模型的要求也不一致，測試目的的定位，也決定了每次測試的方案和偏重點會不同，因此不能一律而全，要區別對待。

    

      咱們通常會有一些以下的區分：

    

     服務器TPS測定，也是定位服務器的最大承載量，咱們須要優先經過壓力測試找到TPS的初始值，而後再進行穩定性測試和容災測試，找到TPS的穩定值範圍在哪裏，最終修正TPS值。

     性能瓶頸定位，經過壓測和關鍵指標數據的收集，定位服務器性能瓶頸的區域。

     關鍵接口指標，針對關鍵接口作一些指標收集。

 

---

 

二、壓力測試

  壓力測試主要是測試服務器在極限狀況下的承載是怎樣的，以及可以達到怎樣的極限值。作壓力測試還須要針對性的編寫一些壓測機器人來幫忙咱們發起密集的請求，以讓服務器達到滿荷的狀態。

 

     咱們的壓測主    要包含這幾個方面：

 

•  1)、指令機器人

         指令機器人是壓測發起 主體，你能夠把他看做爲一個模擬的用戶，模擬用戶的指定行爲，和收集一些關鍵數據。從功能方面來看，機器人主要功能，根據輸入指令，發起特定請求（批量或者單個），收集請求和回覆數據。

        因爲每一個遊戲的業務類型不同，協議也有本身的加解密方式，因此相對要複雜些，並且複用性也比較差。而web方面的指令機器人，簡單易用，只要把關鍵的部分經過元數據來配置，基本能夠作到一次編寫，處處亂用的目的。

 

 

•   2)、指令的錄入

         指令通常都是client向服務器發起的request，每種應用不盡相同，能夠本身編寫指定格式，也能夠在服務器或者客戶端進行指令錄入，由於遊戲協議 的特殊性咱們通常是作錄入來處理，這個也能夠根據本身需求來，主要是保證，指令可以讓方便機器人讀取就行。

 

   

• 3)、數據準備和指標的錄入

    遊戲通常是有狀態的狀況，因此在除了指令錄入還須要準備些初始化的數據，好比模擬賬號，一些道具的初始等等。機器人不但負責請求，還得有必定的數據收集功能，通常的數據包含以下，

     request數量/秒，成功率多少，失敗率多少,還有每一個接口的請求次數，平均耗時等。在騰訊這邊，有時候會須要這些數據上傳到統計平臺，來統計測試的統計圖，作最終的壓測指標。

       這裏給你們截圖一個咱們日常使用的輸出模型:

 

  這個圖我麼能夠看到，總共請求了9960次，成功100%，870次請求／s,,請求間隔時間,11.450s，最快3.3ms,最慢871.6ms。

 

  以上這幾部主要作壓測的基礎功能，在測試的時候，咱們須要把指令機器人跑起來，不斷的加量，看服務器的運行情況，以此來評測服務器的tps。

 

---

 

三、穩定性測試

 穩定性測試就是要測試服務器的穩定性，有時候服務器在功能測試的時候並不能測試到一些情況，好比長時間運行會有資源的沒釋放，致使的GC的問題，或者是DB快速增加後的訪問變慢問題，這些就須要穩定性測試來發現問題。

 

咱們通常在作出壓力測試狀況下，會計算出單臺服務器的tps，而後以此tps壓力下，讓機器人測試19小時以上，期間會檢測服務器相關的cpu，內存，網關流量；邏輯進程相關的，cpu，句柄，gc次數，線程數；緩存服務器的cpu，以及網絡流量等。經過查看這些參數的運行曲線，會很容易發現一些常見的問題。關於這些參數的監控工具，經常使用的有不少，我就不一一推薦了。

 

---

 

四、容災測試

容災測試就是測試下服務器在出現意外的狀況下，如何快速的修復服務或者保障服務器不宕機。

 

在騰訊合做的項目中，通常會有要求30分鐘之內恢復，這個就須要上線前，作一些容災演練，這個期間須要保證每一個組件都可以足夠健壯了，在集羣內的單個組件發生情況了，守護程序可以主動發現並拉起或者報警，備用組件可以即時的跟進，保證不會由於某一個組件出現問題，而致使服務器長時間沒法訪問。

 

咱們通常這麼作，正在運行的服務器中，隨機kill其中一個memcache主機，看守護程序是否能夠快速拉起，會不會出現髒數據。或者在DB方面，kill其中一個主機，看是否實現數據分片後存儲節點的冗餘與互備，在出故障時，有效保障數據處理不間斷

 

---

 

5.關鍵接口測試

每一個系統都有一些關鍵接口，接口的關鍵與否和業務有很大關係。有時候咱們須要拿到這些關鍵接口的指標評估，好比關鍵接口的評估標準，優化先後的數據對比和性能提高對比等。

關鍵接口測試要作到安全穩定，性能提高的前提要保證接口的安全和穩定。

 

以上這些是咱們通常會用到的測試方式，幾種測試方式能夠組合爲一種測試方案，流程也會不相同。固然了通常狀況下，咱們會把這些流程都走一遍，保證不遺漏，數據更全面。

---

 

三，上線服務器的數量的預估

 

 評估上線服務器數量，咱們須要一步步反推。好比，上線的某一段週期內，會有多少流量（用戶）導入，單臺服務器可以承受多少流量，有了這兩個值，預估的服務器數量＝拿總流量／單臺服務器承壓流量。固然了，總會有些偏差，咱們通常還要多處20%的預留，預留你懂的，總有意外，出來了意外總不能去甩鍋吧。

 

上面咱們講了2個關鍵指標，總流量，單臺服務器承壓流量。這裏的流量須要和業務需求掛鉤的，好比BS架構的互聯網產品，PV（點擊）是流量單位，而CS架構的遊戲，則用戶是流量單位。每種業務不一樣評判的標準不盡相同，須要根據本身的需求來。下面我以遊戲爲例來舉慄。

 

前面的測試已經幫咱們拿到重要數據了，TPS，那TPS如何來轉換爲用戶吶？要想講清這個，咱們先回顧下TPS概念，TPS是每秒的事務數，在遊戲裏這裏的單個事務是指一個用戶所執行的一組指令所耗費的時間，是一組而不是一個，爲什麼是一組，由於每一個指令耗費的時間不盡相同，單個指令的TPS毫無疑義，一組才能表明一個用戶的真正行爲。此時TPS就能夠間接轉換爲用戶數了，但還要考慮一個比率問題，真實用戶是沒法達到機器人的水準的，也就是tps轉換用戶數要變大。好比壓測出的機器人tps是1000，機器人執行一組指令須要160s,而真實用戶執行須要1605s,此時的最終單臺服務器承壓用戶數爲1000*10=10000。

 

對於總流量，咱們能夠和運營人員溝通，此次導入的新用戶指標是多少，再根據以往的經驗或者公測數據，就能估算出預計的PCU（同時在線用戶）和DAU是多少。有了PCU，總流量就知道是多少了，最終的服務器數量也能夠預估出來了。

 

對於B/S架構的互聯網產品，我只能淺略的講下以前的經驗了。以前作的時候，上線前可以向運營拿到的數據是推廣量，一個PV(點擊)算一個推廣量單位。咱們是這麼處理的，按照用戶的習慣，咱們的產品通常會在10：00-14：00，16:00-22:00期間達到訪問高峯，也就是10個小時，若是單臺服務器的tps爲10000，單臺服務器的能夠承受的日PV＝10000*10*1（至關於按最高TPS訪問10個小時，不一樣的應用場景會有一些不一樣），有了日PV，那麼咱們預估出服務器數量應該是:總推廣量/單臺服務器的日PV。

 

---

 

4、後續

以上就是一些對服務器上線前的一些測試流程，經過這些流程，咱們就能夠對服務器有一個大概的瞭解，好比 服務器瓶頸會在哪裏 ，出現特殊狀況，如何作預案等。

 

另外測試數據只能提供一個初始值，正在的上線的時候，會出現一些其餘的情況，須要針對測試的數據進行修正，若是誤差比較大，要對不完善的方案進行改進。咱們是不可能預估出真實的數據的，只能無限接近這個值。

 

 還有一些其餘的測試方案和流程我沒有講到，之後再表。測試流程的設定應該根據自身狀況來，不必每步必作，大公司有大公司的規範，小公司有小公司的流程，選擇本身適合的最重要。