在 LoadRunner 的運(yùn)行場景中，有一個(gè)不大起眼的設(shè)置，可能經(jīng)常會(huì)被很多人忽略，它就是 Pacing 。具體設(shè)置方式為： Run-Time settings à General à Pacing ，這個(gè)設(shè)置的功能從字面上就很容易理解，即在場景的兩次迭代 (iteration) 之間，加入一個(gè)時(shí)間間隔（步進(jìn)）。設(shè)置方法也很簡單，這里就不贅述了，我在這里想說明的是，這個(gè)設(shè)置到底有什么作用？為什么要進(jìn)行這個(gè)設(shè)置？說實(shí)話，雖然我在以前做過的一些性能測試中，偶爾會(huì)對這個(gè)步進(jìn)值進(jìn)行一些設(shè)置，但其實(shí)對它的真正含義和作用，我還并不十分清楚。

前段時(shí)間，我在對X銀行招聘信息系統(tǒng)進(jìn)行性能測試的時(shí)候，發(fā)現(xiàn)這個(gè)值的設(shè)置對于測試的結(jié)果有著很大的影響，很遺憾當(dāng)時(shí)沒有深入研究這個(gè)問題，而只是簡單地認(rèn)為它同腳本中的 thinktime 一樣只是為了更真實(shí)地模擬實(shí)際情況而已。最近在網(wǎng)絡(luò)上看到一篇題為《調(diào)整壓力測試工具》的文章，讀完之后，再用之前我的測試經(jīng)歷加以印證，真有種豁然開朗的感覺。以下就將我的一些體會(huì)與大家分享：

通常我們在談到一個(gè)軟件的“性能”的時(shí)候，首先想到的就是“響應(yīng)時(shí)間”和“并發(fā)用戶數(shù)”這兩個(gè)概念。我們看到的性能需求經(jīng)常都是這樣定義的：

“要求系統(tǒng)支持 100 個(gè)并發(fā)用戶”

看到這樣的性能需求，我們往往會(huì)不假思索地就在測試場景中設(shè)置 100 個(gè)用戶，讓它們同時(shí)執(zhí)行某一個(gè)測試腳本，然后觀察其操作的響應(yīng)時(shí)間，我們都是這樣做的，不是嗎？我在實(shí)際實(shí)施性能測試的過程中，也往往都是這樣做的。可惜的是，我們中的大多數(shù)人很少去更深入地思考一下其中的奧妙，包括我自己。

事實(shí)上，評價(jià)一個(gè)軟件系統(tǒng)的性能，可以從兩個(gè)不同的視角去看待：客戶端視角和服務(wù)器視角（也有人把它叫做用戶視角和系統(tǒng)視角），與此相對應(yīng)的，又可以引出兩個(gè)讓初學(xué)者很容易混淆的兩個(gè)概念：“并發(fā)用戶數(shù)”和“每秒請求數(shù)”。“并發(fā)用戶數(shù)”是從客戶端視角去定義的，而“每秒請求數(shù)”則是從服務(wù)器視角去定義的。

因此，上面所描述的做法的局限性就是，它反映的僅僅是客戶端的視角。

對于這個(gè)世界上的很多事情，變換不同的角度去看它，往往可以有助于我們得到更正確的結(jié)論。現(xiàn)在，我們就轉(zhuǎn)換一下角度，以服務(wù)器的視角來看看性能需求應(yīng)該怎么樣定義：

“要求系統(tǒng)的事務(wù)處理能力達(dá)到 100 個(gè) / 秒” ( 這里為了理解的方便，假定在測試腳本中的一個(gè)事務(wù)僅僅包含一次請求 )

面對以這樣方式提出的性能需求，在 LoadRunner 中，我們又該如何去設(shè)置它的并發(fā)用戶數(shù)呢？千萬不要想當(dāng)然地以為設(shè)置了 100 個(gè)并發(fā)用戶數(shù)，它就會(huì)每秒向服務(wù)器提交 100 個(gè)請求，這是兩個(gè)不同的概念，因?yàn)?/span> LoadRunner 模擬客戶端向服務(wù)器發(fā)出請求，必須等待服務(wù)器對這個(gè)請求做出響應(yīng)，并且客戶端收到這個(gè)響應(yīng)之后，才會(huì)重新發(fā)出新的請求，而服務(wù)器對請求的處理是需要一個(gè)時(shí)間的。我們換個(gè)說法，對于每個(gè)虛擬用戶來說，它對服務(wù)器發(fā)出請求的頻率將依賴于服務(wù)器對這個(gè)請求的處理時(shí)間。而服務(wù)器對請求的處理時(shí)間是不可控的，如果我們想要在測試過程中維持一個(gè)穩(wěn)定的每秒請求數(shù)（ RPS ），只有一個(gè)方法，那就是通過增加并發(fā)用戶數(shù)的數(shù)量來達(dá)到這個(gè)目的。這個(gè)方法看起來似乎沒有什么問題，如果我們在測試場景中只執(zhí)行一次迭代的話。然而有經(jīng)驗(yàn)的朋友都會(huì)知道，實(shí)際情況并不是這樣，我們通常會(huì)對場景設(shè)置一個(gè)持續(xù)運(yùn)行時(shí)間（即多次迭代），通過多個(gè)事務(wù) (transaction) 的取樣平均值來保證測試結(jié)果的準(zhǔn)確性。測試場景以迭代的方式進(jìn)行，如果不設(shè)置步進(jìn)值的話，那么對于每個(gè)虛擬用戶來說，每一個(gè)發(fā)到服務(wù)器的請求得到響應(yīng)之后，會(huì)馬上發(fā)送下一次請求。同時(shí)，我們知道， LoadRunner 是以客戶端的角度來定義“響應(yīng)時(shí)間”的 ，當(dāng)客戶端請求發(fā)出去后， LoadRunner 就開始計(jì)算響應(yīng)時(shí)間，一直到它收到服務(wù)器端的響應(yīng)。這個(gè)時(shí)候問題就產(chǎn)生了：如果此時(shí)的服務(wù)器端的排隊(duì)隊(duì)列已滿，服務(wù)器資源正處于忙碌的狀態(tài)，那么該請求會(huì)駐留在服務(wù)器的線程中，換句話說，這個(gè)新產(chǎn)生的請求并不會(huì)對服務(wù)器端產(chǎn)生真正的負(fù)載，但很遺憾的是，該請求的計(jì)時(shí)器已經(jīng)啟動(dòng)了，因此我們很容易就可以預(yù)見到，這個(gè)請求的響應(yīng)時(shí)間會(huì)變得很長，甚至可能長到使得該請求由于超時(shí)而失敗。等到測試結(jié)束后，我們查看一下結(jié)果，就會(huì)發(fā)現(xiàn)這樣一個(gè)很不幸的現(xiàn)象：事務(wù)平均響應(yīng)時(shí)間很長，最小響應(yīng)時(shí)間與最大響應(yīng)時(shí)間的差距很大，而這個(gè)時(shí)候的平均響應(yīng)時(shí)間，其實(shí)也就失去了它應(yīng)有的意義。也就是說，由于客戶端發(fā)送的請求太快而導(dǎo)致影響了實(shí)際的測量結(jié)果。

因此，為了解決這個(gè)問題，我們可以在每兩個(gè)請求之間插入一個(gè)間隔時(shí)間，這將會(huì)降低單個(gè)用戶啟動(dòng)請求的速度。間歇會(huì)減少請求在線程中駐留的時(shí)間，從而提供更符合現(xiàn)實(shí)的響應(yīng)時(shí)間。這就是我在文章開頭所提到的 Pacing 這個(gè)值的作用。

最后再補(bǔ)充一句話：雖然性能測試通常都是從客戶端活動(dòng)的角度定義的，但是它們應(yīng)該以服務(wù)器為中心的視角來看待。請注意這句話，理解它很重要，只有真正理解了這句話，你才會(huì)明白為什么我們一直強(qiáng)調(diào)做性能測試的時(shí)候要保證一個(gè)獨(dú)立、干凈的測試環(huán)境，以及一個(gè)穩(wěn)定的網(wǎng)絡(luò)，因?yàn)槲覀兿Ｍu價(jià)的是軟件系統(tǒng)真正的性能，所以必須排除其它一切因素對系統(tǒng)性能造成的影響。

花了幾天的時(shí)間才完成這篇文章，如果它能夠幫助大家對性能測試多一些理解或者多一些思考，那就是我的榮幸了。 ^_^

?

?

?

?

參考資料：

Kirk Pepperdine 《 Tuning your stress test harness 》

http://www.theserverside.com/tt/articles/article.tss?l=StressTest