探討性能測試的負載目標
性能測試主要評價系統或組件的性能是否和具體的性能需求一致，例如：對訪問速度的性能需求或對內存使用情況的需求。特定性能測試的關注點在于組件或系統在規定的時間內和特定的條件下響應用戶或系統輸入的能力。
一、前提
近期我跟蹤了2個外協人員參與的性能測試項目，溝通中發現大家在制定測試策略時對如何確定負載目標、計算并發用戶數量等方面有很多不同方法，本文希望能對各種方法進行探討，并根據已有經驗對策略制定方面給出一些自己的建議。本文被測應用以銀行系統為主，壓力發起工具以LoadRunner為例。
二、術語
單位時間：本文中以1秒為單位時間。
在線用戶數量：訪問被測應用的用戶數量，但單位時間內用戶不會同時對被測服務器發送請求，產生壓力。
并發用戶數量：部分書中分狹義和廣義兩種，狹義指單位時間內同時執行一種操作的用戶數量，廣義指單位時間內同時執行多種不同操作的用戶數量，廣義的并發用戶操作更接近實際業務環境。但本文中的并發用戶數量僅指狹義而言，因為廣義是多種狹義的組合。
TPS：Transaction per Second，每秒事務數量，單位是事務/秒。
TRT：Transaction Response Time，事務響應時間，指TPS穩定時的平均事務響應時間，單位是秒。
三、負載目標
1. 負載視角
制定測試策略是性能測試的重點，包括測試范圍、場景提取、負載目標、發起方式、通過標準等。而負載目標關系整個測試的場景設計、并發配比、結果評判，因此確定負載目標也決定了測試的總體方向。通過了解業務需求，負載目標都會轉化為一系列具體的數值，一般可從兩方面來劃分：
前端：業務人員更關注前端并發用戶數量或在線用戶數量，以人數衡量；
后端：技術人員更關注后端應用服務器和數據庫服務器的負載能力，以TPS衡量；
前端并發用戶數量的計算在業界中有很多公式和原則，如2/8原則、10%在線用戶數量估算、（在線用戶數量*session時間）/監控時間等，但各公式和原則計算出的并發用戶數量并不精確，如有10萬在線用戶的系統不能說僅測試10萬*10%=1萬并發用戶即可。
后端TPS反應被測應用的實際負載能力，對已有具體業務量的應用可以計算精確，如銀行系統中某省行對公交易量日均10萬筆，則可精確計算出TPS均值=10萬/（6*3600）=4.63筆/秒（對公業務按6小時計算），若被測應用達不到TPS要求則完成不了當日業務。
同一個被測應用以不同視角估算負載目標，得到的數值可能會有很大差異，因此如何正確選擇負載目標，將會直接影響之后的測試方法和場景設計。
2. 負載指標
拋開視角的選擇，單從最終測試指標來說，對于一個軟硬件環境固定的應用程序，只有一個負載指標是固定的，那就是***事務處理能力 – 通常以TPS衡量。隨著負載的增加，被測應用將會逐漸達到***事務處理能力，若應用足夠健壯，則負載繼續增加，應用的事務處理能力也不會驟然下降。因此性能測試的目標就是確定被測應用的***事務處理能力。以事務處理能力反推，將逐漸捋清TPS、TRT、并發用戶數量、在線用戶數量等負載目標的關系和估算。
1）TPS
Transaction的粒度會直接影響TPS的計算，因此Transaction定義時要保證粒度適當：
C/S架構聯機類應用中一筆交易往往會流經多層前置應用，需要確定壓力發起工具所在位置，建議跨過前端直壓被測應用，此時一個Transaction代表一支后臺交易。
B/S架構經管類應用中一個頁面操作可能會和后臺有多次交互，建議以頁面上的操作為Transaction劃分基準，但要保證Transaction內的交互操作在前端是不可再拆分的。
LoadRunner發起壓力時Action內的語句是反復迭代的，而LR計算TPS僅看1秒內執行了幾次Transaction，如果Action內有多個Transaction則各事務的TPS都一樣，反應不出各事務的真實處理能力，因此建議Action內只定義一個或盡量精簡的Transaction。
由此TPS才可以準確表示被測應用的事務處理能力。
通過獲取生產日志、參考相似系統等方式能夠得到具體交易（事務）數量的被測應用程序，以TPS為負載目標是直接也最準確的。但要注意，若以TPS為目標，則前端配置的并發數量就不再代表并發人數，而是并發提交事務的數量。TPS和TRT的計算關系將在下面詳述。
2）TRT
TRT指TPS穩定時（不一定是***時）的平均事務響應時間，不關注個別事務，它和TPS關系緊密，隨TPS的變化而變化。當負載增加時TRT會逐漸增大，直至事務阻塞，交易超時。
TPS × TRT = 并發提交事務的數量。如果以TPS=20為目標，且此時TRT=2秒，則并發提交事務的數量=20×2=40筆。如果1個用戶單位時間內提交1筆事務，則可等于有40個并發用戶數量。
設定好目標TPS后要同時兼顧TRT的表現，若TRT明顯超出業務要求，即使達到負載目標也是無效的。TRT無固定的好壞標準，一般來說對OLTP的聯機應用，從前端提交到返回不應高于3秒，后臺應用程序和數據庫的處理應在1秒左右。對OLAP的在線分析系統或一般網站可遵循3/5/8原則，或更長。
3）并發用戶數量
通常理解并發用戶數量就是LoadRunner里設置的VUser數量，通過梯度增加VUser，對比TPS變化即可找到被測應用的***并發用戶。但我卻認為并發用戶數量不等于LoadRunner中設置的VUser數量。受交易響應時間、thinktime、pacing和集合點等因素影響，VUser數量不能直接體現被測應用負載能力。假設同樣10個VUser并發一次，如果A程序的響應時間是1秒，則A程序的TPS=10/1=10。而B程序的響應時間是5秒，則B程序的TPS=10/5=2。同樣在混合場景中用VUser比例體現不同應用的負載比例也是錯誤的，混合場景下由于各交易相互影響，單交易負載時響應快的很可能現在出現阻塞，前端VUser的比例根本無法準確控制后端應用的壓力。
因此我更愿意將“并發用戶數量”和“并發提交事務數量”掛鉤，體現被測應用實際負載：單位時間內n個用戶并發向被測應用提交n個事務請求（n是相同的）。VUser的數量和發起設置只是實現并發用戶數量的一種手段。
4）在線用戶數量
在線用戶數量與并發用戶數量、TPS、TRT間沒有固定的換算公式，我不提倡10%這樣的粗糙比例，對聯機類應用在線用戶就是每天簽到的柜員數量，對經管類應用就是月末、季末時所有登錄系統的用戶數量。在線用戶數量可以從需求人員或生產管理員處獲得大概數值，但不能通過性能測試倒推出在線數量。
四、負載目標選擇
1. 有明確交易量的應用
通過上面對各種典型負載指標的分析可以看出，以TPS衡量的事務處理能力是最準確的負載目標。通過生產日志或相似系統的交易量可以算出TPS均值、峰值。根據2/8原則和業務擴展可估算更高的峰值。銀行的聯機類應用屬于典型的有明確交易量的應用系統。
LoadRunner中可以通過設置Run-Time Settings的Pacing為At fixed intervals， every 1 sec，來控制每次迭代執行時間為1秒。如果迭代腳本里只定義一個Transaction，且TRT小于1秒，則VUser數量=并發用戶數量=TPS，可以通過調節VUser數量方便控制負載目標。注意，如果迭代中包含多個Transaction，或TRT隨著TPS目標的增加而變大，則需以TPS目標為基礎，實時調整VUser數量和這里every N sec里的間隔時間。
2. 無明確交易量的應用
無明確交易量的被測應用建議以確定***事務處理能力為目標。設置Pacing為As soon as the previous iteration ends，刪除thinktime，部署發壓工具和被測應用在同一網段，無網絡瓶頸，讓VUser能對被測應用產生***負載。弱化VUser數量聽上去的意義，遞增直到達到被測應用的***事務處理能力或其他性能指標閥值（如成功率或TRT）。新業務和經管類Web應用屬于無明確交易量的應用系統。
3. VUser的意義
盡管建議在確定負載目標時弱化VUser的意義，但測試中還要注意一種情況，如果被測應用有具體的操作用戶數量，如只有簽到或登錄的用戶才能提交交易，則VUser的數量不能高于實際注冊用戶數量。就按照***用戶數量加壓，以需求要求的TRT為目標調優被測應用，盡量提高TPS。
希望本文能給你帶來幫助。
【編輯推薦】
