一、性能指標

我們知道服務器，有 CPU、內(nèi)存、IO、網(wǎng)絡等一系列指標，除了這些系統(tǒng)級的，還有些針對各個語言自己的性能參數(shù)，而一個服務器的吞度量與請求對CPU的消耗、外部接口、IO等等緊密關聯(lián)的?,面對這么多繁雜的參數(shù)我們?nèi)绾斡行Ф焖俚睦?如何評估這些性能參數(shù)信息? 下面我以游戲服務器來為例說一下我們主要關注點。

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

并發(fā)數(shù):并發(fā)請求數(shù)

響應時間:平均響應時間

TPS:每秒鐘處理事務數(shù)量

TPS =并發(fā)數(shù)/響應時間

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

二、上線前的測試流程

1、測試模型設計

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

我們一般會有一些如下的區(qū)分：

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

性能瓶頸定位，通過壓測和關鍵指標數(shù)據(jù)的收集，定位服務器性能瓶頸的區(qū)域。

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

2、壓力測試

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

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

1)、指令機器人

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

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

2)、指令的錄入

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

3)、數(shù)據(jù)準備和指標的錄入

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

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

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

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

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

3、穩(wěn)定性測試

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

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

4、容災測試

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

在騰訊合作的項目中，一般會有要求30分鐘以內(nèi)恢復，這個就需要上線前，做一些容災演練，這個期間需要保證每個組件都能夠足夠健壯了，在集群內(nèi)的單個組件發(fā)生狀況了，守護程序能夠主動發(fā)現(xiàn)并拉起或者報警，備用組件能夠即時的跟進，保證不會因為某一個組件出現(xiàn)問題，而導致服務器長時間無法訪問。

我們一般這么做，正在運行的服務器中，隨機kill其中一個memcache主機，看守護程序是否可以快速拉起，會不會出現(xiàn)臟數(shù)據(jù)。或者在DB方面，kill其中一個主機，看是否實現(xiàn)數(shù)據(jù)分片后存儲節(jié)點的冗余與互備，在出故障時，有效保障數(shù)據(jù)處理不間斷

5.關鍵接口測試

每個系統(tǒng)都有一些關鍵接口，接口的關鍵與否和業(yè)務有很大關系。有時候我們需要拿到這些關鍵接口的指標評估，比如關鍵接口的評估標準，優(yōu)化前后的數(shù)據(jù)對比和性能提升對比等。

關鍵接口測試要做到安全穩(wěn)定，性能提升的前提要保證接口的安全和穩(wěn)定。

以上這些是我們一般會用到的測試方式，幾種測試方式可以組合為一種測試方案，流程也會不相同。當然了一般情況下，我們會把這些流程都走一遍，保證不遺漏，數(shù)據(jù)更全面。

三，上線服務器的數(shù)量的預估

評估上線服務器數(shù)量，我們需要一步步反推。比如，上線的某一段周期內(nèi)，會有多少流量(用戶)導入，單臺服務器能夠承受多少流量，有了這兩個值，預估的服務器數(shù)量＝拿總流量／單臺服務器承壓流量。當然了，總會有些誤差，我們一般還要多處20%的預留，預留你懂的，總有意外，出來了意外總不能去甩鍋吧。

上面我們講了2個關鍵指標，總流量，單臺服務器承壓流量。這里的流量需要和業(yè)務需求掛鉤的，比如BS架構的互聯(lián)網(wǎng)產(chǎn)品，PV(點擊)是流量單位，而CS架構的游戲，則用戶是流量單位。每種業(yè)務不同評判的標準不盡相同，需要根據(jù)自己的需求來。下面我以游戲為例來舉栗。

前面的測試已經(jīng)幫我們拿到重要數(shù)據(jù)了，TPS，那TPS如何來轉換為用戶吶？要想講清這個，我們先回顧下TPS概念，TPS是每秒的事務數(shù)，在游戲里這里的單個事務是指一個用戶所執(zhí)行的一組指令所耗費的時間，是一組而不是一個，為何是一組，因為每個指令耗費的時間不盡相同，單個指令的TPS毫無疑義，一組才能代表一個用戶的真正行為。此時TPS就可以間接轉換為用戶數(shù)了，但還要考慮一個比率問題，真實用戶是無法達到機器人的水準的，也就是tps轉換用戶數(shù)要變大。比如壓測出的機器人tps是1000，機器人執(zhí)行一組指令需要160s,而真實用戶執(zhí)行需要1605s,此時的最終單臺服務器承壓用戶數(shù)為1000*10=10000。

對于總流量，我們可以和運營人員溝通，這次導入的新用戶指標是多少，再根據(jù)以往的經(jīng)驗或者公測數(shù)據(jù)，就能估算出預計的PCU(同時在線用戶)和DAU是多少。有了PCU，總流量就知道是多少了，最終的服務器數(shù)量也可以預估出來了。

對于B/S架構的互聯(lián)網(wǎng)產(chǎn)品，我只能淺略的講下之前的經(jīng)驗了。之前做的時候，上線前能夠向運營拿到的數(shù)據(jù)是推廣量，一個PV(點擊)算一個推廣量單位。我們是這么處理的，按照用戶的習慣，我們的產(chǎn)品一般會在10：00-14：00，16:00-22:00期間達到訪問高峰，也就是10個小時，如果單臺服務器的tps為10000，單臺服務器的可以承受的日PV＝10000*10*1(相當于按最高TPS訪問10個小時，不同的應用場景會有一些不同)，有了日PV，那么我們預估出服務器數(shù)量應該是:總推廣量/單臺服務器的日PV。

四、后續(xù)

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

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

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。