探討性能測試的負載目標(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。
希望本文能給你帶來幫助。
【編輯推薦】