一、性能指標

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

我們主要關注以下3個點:

并發數:并發請求數

響應時間:平均響應時間

TPS:每秒鐘處理事務數量

TPS =并發數/響應時間

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

二、上線前的測試流程

1、測試模型設計

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

我們一般會有一些如下的區分：

服務器TPS測定，也是定位服務器的最大承載量，我們需要優先通過壓力測試找到TPS的初始值，然后再進行穩定性測試和容災測試，找到TPS的穩定值范圍在哪里，最終修正TPS值。

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

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

2、壓力測試

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

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

1)、指令機器人

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

由于每個游戲的業務類型不一樣，協議也有自己的加解密方式，所以相對要復雜些，而且復用性也比較差。而web方面的指令機器人，簡單易用，只要把關鍵的部分通過元數據來配置，基本可以做到一次編寫，到處亂用的目的。

2)、指令的錄入

指令一般都是client向服務器發起的request，每種應用不盡相同，可以自己編寫指定格式，也可以在服務器或者客戶端進行指令錄入，因為游戲協議 的特殊性我們一般是做錄入來處理，這個也可以根據自己需求來，主要是保證，指令能夠讓方便機器人讀取就行。

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

游戲一般是有狀態的情況，所以在除了指令錄入還需要準備些初始化的數據，比如模擬帳號，一些道具的初始等等。機器人不但負責請求，還得有一定的數據收集功能，一般的數據包含如下，

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

這里給大家截圖一個我們平常使用的輸出模型:

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

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

3、穩定性測試

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

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

4、容災測試

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

在騰訊合作的項目中，一般會有要求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。

四、后續

以上就是一些對服務器上線前的一些測試流程，通過這些流程，我們就可以對服務器有一個大概的了解，比如 服務器瓶頸會在哪里 ，出現特殊情況，如何做預案等。

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

還有一些其他的測試方案和流程我沒有講到，以后再表。測試流程的設定應該根據自身情況來，沒必要每步必做，大公司有大公司的規范，小公司有小公司的流程，選擇自己適合的最重要。

總結

以上是生活随笔為你收集整理的服务器每秒钟执行命令数量是什么_如何合理的评估上线服务器数量的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。