效能測試的幾種業務模型設計

標籤：

一個訪問量達到百萬層級的門戶網站及奧運會訂票系統等這中使用者數較多的系統，進行效能測試是必須的。要不就和產品示範會上出現的笑話一樣，風險投資商提出的問題是這個網站能支援多少使用者同時上線，專案經理居然說沒有進行這方面的測試。全場嘩然。。。。

　　對於效能測試的第一步是怎麼去根據業務的實際模型分析出具體的測試情境及效能測試的指標。

　　一、 效能測試商務邏輯理解的一些基本概念

　　1、負載測試和壓力測試的區別：負載測試在於確定最終滿足系統指標的前提下，系統所能承受的最大負載測試，壓力測試的目標則在確定什麼條件下系統效能處於失效狀態。

　　2、輸送量(Throughput)：指單位時間內處理的客戶段請求數量，直接體現軟體系統的效能承載能力。

　　3、並發(Concurrency)：多個同時發生的業務操作。例如100個使用者同時點登入21CN郵箱和同時線上人數不一樣。比如說21CN 通行證使用者登入的有1萬個可能只有20%的人在看部落格，10%的人在看相簿，30%的人在查看郵件，10%的人在查看播客，10%的人在看視頻點 播，10%的人在逛論壇等等

　　但是同時線上人數就是1萬，並發使用者就是針對每個系統的具體人數。

　　二、幾種常見的業務模型設計

　　1、e家廣告系統：

　　(1)具體的業務參數要求：

　　系統要達到4000萬日均PV，則需要平台可以處理4000並發/秒。根據選中的伺服器的效能，處理能力約為2000個HTTP並發/秒或1000個流媒體並發/秒。假設這4000萬PV中有圖片的PV佔3000萬，流媒體的PV佔1000萬，則需要WEB伺服器及流媒體伺服器各兩台。

　　(2)具體的測試設計方法：

　　(a)平台的處理能力與要達到的日均PV的能力的計算關係為：

　　參數說明：

　　X：表示整個系統的日均PV值，單位為：萬PV/天

　　m：平台最大有效並發數(即用來服務於廣告物料顯示的並發數)，單位為：並發/秒，每小時是3600秒，即每個小時處理的並發數為3600m並發，即0.36m萬並發/小時。

　　y：非高峰時期的平均並發數與平台最大並發數的比例，0

　　Y：高峰期(平台達到最大並發數的70%，平台負載超過70%以後，將變得不穩定)小時數,0

　　那麼：

　　日均PV=高峰期並發數*高峰期小時數+非高峰期平均並發數*(24-高峰期小時數)

　　即：

　　X=0.7*0.36mY+y*0.36m*(24-Y)

　　即最後結論：

　　X=(0.252Y+8.64y-0.36yY)*m

　　根據經驗值，Y=3，y=30%時，m/X=0.33。而m是平台最大有效並發數，即用來服務於廣告物料顯示的並發數，而對於每次廣告物料的顯示，用戶端還有訪問其它資源如JS代碼等，假設每一次廣告物料的訪問會有伴隨另外2個資源的訪問。

　　那麼平台支撐的總的並發數與需要達到的日均PV的比大約為0.33*3=1。

　　(b)實際測試模型設計中結果：

　　對廣告連結頁面的並發使用者數只需要達到N1=0.33*40000000*0.7/24*0.3*3600=356個

　　對於流媒體伺服器並發使用者數：N2=10000000*0.7/24*0.3*3600/2=135個

　　對於圖片伺服器並發使用者數：N3=30000000*0.7/24*0.3*3600/2=405個

　　2、集團郵箱：

　　(1)具體的業務參數要求：集團郵箱支援支援2000萬使用者，對效能有要求的操作有郵箱登入，讀信，翻頁，發郵件(分別是8秒內，2秒內，2秒 內，5秒內)。所有的操作均返回HTTP200的狀態碼。其中伺服器資源分別是登入5台機器(串連PASSPORT)，收發郵件5台(不包括POP收發 信)，其它郵件處理伺服器5台，pop/smtp伺服器5台。

　　(2)具體的測試設計方法：具體的設計2000萬個使用者登入時間大概在會在8點到下午18點前操作，而該類業務模型滿足80~20原則，比如 80%的業務會在20%的時間內處理。則登入的並發使用者數設計成多少好呢? VUlogin=20000000*80%/(10*20%*3600*5) 其它事物可以以此類推。

　　(3)當然如果業務在要求輸送量的時候，就要更根據輸送量來設計效能瓶頸所需要的並發使用者數這在我們21CN網站和電子商務網站中經常出現。這 裡引進一個公式VU=F /R*T(VU並發虛擬使用者數,F輸送量,T效能測試時間,R每個VU的請求數量)舉例說明(某網站的輸送量為90億KB，每個使用者每秒50萬kb，運行 時間30分鐘設計出來的每秒使用者數VU=9000000000/(500000*30*30))

　　(4)如辦公系統(業務比較頻繁的系統)：每天內的一些典型使用者固定可以考慮採用一種更準確的計算並發使用者數的的方法。公式引 進：C=N*L/T,C1=C+ (C是平均並發使用者數，N是login session的數量，L是login session的時間長度，T是考察的時間長度，C1是最高峰值)(*這裡的使用者是指明確每天都要使用的系統的大概數量來自需求， 而這裡的使用者都是當做一個典型的使用者來分析就是登入後會進行正常的流程操作)如21CNEIP每天有320個典型使用者訪問，系統平均時間為4小時，在一天 內使用者使用該系統的時間都在8小時內。得出C=320*4/8,C1=C+3 (5)針對這幾種模式做一些歸納無論那種模型都是來源於需求根據需求的實際模型是最真實的也是最有效效能測試模型，在沒有典型使用者的前提下選擇2-8原 則(在測試環境中 要考慮到等價這個概念就是測試環境伺服器數量沒有實際環境哪麼多的時候要折算過來)，有典型使用者的情況下選擇最大並發數的計算方法，在要求有輸送量的情況 下用輸送量的計算方法(但是輸送量的資料要採用上一次測試或者經驗值中沒有突破系統瓶頸的部分資料要不結果不準確，其中每秒事物數取的是平均值)

　　三、其它值得注意部分

　　1、設定測試情境中並發使用者為每隔一段時間增加X個虛擬使用者(預熱，RAMP UP設定)，與同時載入所有的並發使用者的測試結果不同，實際的測試中要根據具體業務情況設計。另外實際的資料庫記錄數和網路環境等都會影響到測試結果。

　　2、建議在實際的測試過程中能多次測試取平均值。

　　3、效能測試的”拐點論”:產生拐點的情況是效能測試產生某種瓶頸，主要原因是某種資源達到了極限。此時表現為隨著壓力的增大，系統效能出現急劇下降。

　　4、效能測試的系統能力驗證: (a)是系統穩定性的一個基本要求，通常表現為系統在要求的平均並發使用者下伺服器的CPU平均使用率不高於75%，記憶體的使用率不高於75%。(b)系統 在要求的並發使用者數達到峰值情況下伺服器的CPU平均使用率不高於95%，記憶體的使用率不高於90%。(c)系統能在高於實際系統運行壓力1倍的情況下， 穩定的運行72小時。

　　5、為分清各個不同事物的回應時間請務必在多事物的指令碼中添加事物以便區分，請在要用到多個帳戶或者多個使用者的迭代或者迴圈操作的時候請務必進行參數化(很多系統都限制了同一帳戶在多長時間的操作，或者防止資料衝突)。

效能測試的幾種業務模型設計