性能測試相關知識小結

一個web請求的通常步驟

      Web性能測試的部分概況通常來講，一個Web請求的處理包括如下步驟： 

1. 客戶發送請求 

2. web server接受到請求，進行處理； 

3. web server向DB/cache獲取數據； 

4. webserver生成用戶的object(頁面)，返回給用戶。給客戶發送請求開始到最後一個字節的時間稱爲響應時間（第三步不包括在每次請求處理中）。 

服務器計算
服務器數量 =   ceil( 天天總PV / 單臺服務器天天總PV )

原理：天天80%的訪問集中在20%的時間裏，這20%時間叫作峯值時間
公式：( 總PV數 * 80% ) / ( 天天秒數 * 20% ) = 峯值時間每秒請求數(QPS)
機器：峯值時間每秒QPS / 單臺機器的QPS   = 須要的機器

問：天天300w PV 的在單臺機器上，這臺機器須要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

問：若是一臺機器的QPS是58，須要幾臺機器來支持？
答：139 / 58 = 3問：若是一臺機器的QPS是58，須要幾臺機器來支持？
答：139 / 58 = 3

問：若是一臺機器的QPS是58，須要幾臺機器來支持？
答：139 / 58 = 3

問：若是一臺機器的QPS是58，須要幾臺機器來支持？
答：139 / 58 = 3

• 壓測時時刻關注本身的請求是否真正的壓測到了，這時須要本身模擬單個請求的時候跟蹤下數據流向，是否達到了測試的目的；

• 在點對點壓測的時候，時刻注意本身是否配置的host合適；

• 針對一些異常的結果，要有本身的分析和判斷，不要隨便把結果歸結爲工具誤報

相關名詞解釋

        一、事務（Transaction） 

        在web性能測試中，一個事務表示一個「從用戶發送請求->web server接受到請求，進行處理-> web server向DB獲取數據->生成用戶的object(頁面)，返回給用戶」的過程，通常的響應時間都是針對事務而言的。 

 

        二、請求響應時間 
        請求響應時間指的是從客戶端發起的一個請求開始，到客戶端接收到從服務器端返回的響應結束，這個過程所耗費的時間，在某些工具中，響應一般會稱爲「TTLB」，即"time to last byte"，意思是從發起一個請求開始，到客戶端接收到最後一個字節的響應所耗費的時間，響應時間的單位通常爲「秒」或者「毫秒」。一個公式能夠表示：響應時間＝網絡響應時間+應用程序響應時間。

        爲了排除網絡延時干擾測試結果，通常來講咱們作性能測試時都是選擇同機房下的2臺，分別爲客戶端（能夠適當增長客戶端機器數量）和服務端，來進行壓力測試。通常咱們認爲，請求平均耗時不超過200ms、90%的請求的處理時間在200ms如下、失敗請求數不超過1%、服務端cpu消耗不超過80%，則認爲該接口性能良好。

 

        三、事務響應時間 
        事務可能由一系列請求組成,事務的響應時間主要是針對用戶而言,屬於宏觀上的概念，是爲了向用戶說明業務響應時間而提出的.例如:跨行取款事務的響應時間就是由一系列的請求組成的.事務響應時間是直接衡量系統性能的參數. 

        4.併發用戶數 
        併發通常分爲2種狀況。一種是嚴格意義上的併發，即全部的用戶在同一時刻作同一件事情或者操做，這種操做通常指作同一類型的業務。好比在信用卡審批業務中，必定數目的擁護在同一時刻對已經完成的審批業務進行提交；還有一種特例，即全部用戶進行徹底同樣的操做，例如在信用卡審批業務中，全部的用戶能夠一塊兒申請業務，或者修改同一條記錄。 
　　另一種併發是廣義範圍的併發。這種併發與前一種併發的區別是，儘管多個用戶對系統發出了請求或者進行了操做，可是這些請求或者操做能夠是相同的，也能夠是不一樣的。對整個系統而言，仍然是有不少用戶同時對系統進行操做，所以也屬於併發的範疇。 

　　能夠看出，後一種併發是包含前一種併發的。並且後一種併發更接近用戶的實際使用狀況，所以對於大多數的系統，只有數量不多的用戶進行「嚴格意義上的併發」。對於WEB性能測試而言，這2種併發狀況通常都須要進行測試，一般作法是先進行嚴格意義上的併發測試。嚴格意義上的用戶併發通常發生在使用比較頻繁的模塊中，儘管發生的機率不是很大，可是一旦發生性能問題，後果極可能是致命的。嚴格意義上的併發測試每每和功能測試關聯起來，由於併發功能遇到異常一般都是程序問題，這種測試也是健壯性和穩定性測試的一部分。 
用戶併發數量：關於用戶併發的數量，有2種常見的錯誤觀點。 一種錯誤觀點是把併發用戶數量理解爲使用系統的所有用戶的數量，理由是這些用戶可能同時使用系統；還有一種比較接近正確的觀點是把在線用戶數量理解爲併發用戶數量。實際上在線用戶也不必定會和其餘用戶發生併發，例如正在瀏覽網頁的用戶，對服務器沒有任何影響，可是，在線用戶數量是計算併發用戶數量的主要依據之一。

 
        5.吞吐量 
        指的是在一次性能測試過程當中網絡上傳輸的數據量的總和.吞吐量/傳輸時間,就是吞吐率. 

        六、TPS（transactionper second）即QPS
        每秒鐘系統可以處理的交易或者事務的數量.它是衡量系統處理能力的重要指標. 

        QPS = req/sec = 請求數/秒

        【QPS計算PV和機器的方式】

        QPS統計方式 [通常使用 http_load 進行統計]
        QPS = 總請求數 / ( 進程總數 *   請求時間 )
        QPS: 單個進程每秒請求服務器的成功次數

 

【單臺服務器天天PV計算】

       公式1：天天總PV = QPS * 3600 * 6
       公式2：天天總PV = QPS * 3600 * 8

       服務器計算
       服務器數量 =   ceil( 天天總PV / 單臺服務器天天總PV )

【峯值QPS和機器計算公式】

      原理：天天80%的訪問集中在20%的時間裏，這20%時間叫作峯值時間
      公式：( 總PV數 * 80% ) / ( 天天秒數 * 20% ) = 峯值時間每秒請求數(QPS)
      機器：峯值時間每秒QPS / 單臺機器的QPS   = 須要的機器

      問：天天300w PV 的在單臺機器上，這臺機器須要多少QPS？
      答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

      問：若是一臺機器的QPS是58，須要幾臺機器來支持？
      答：139 / 58 = 3

 

注意的問題點

• 壓測時時刻關注本身的請求是否真正的壓測到了，這時須要本身模擬單個請求的時候跟蹤下數據流向，是否達到了測試的目的；

• 在點對點壓測的時候，時刻注意本身是否配置的host合適；

• 針對一些異常的結果，要有本身的分析和判斷，不要隨便把結果歸結爲工具誤報