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