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

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

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

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

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

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

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

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

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

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

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

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

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

?

?

?

?

參考資料：

Kirk Pepperdine 《 Tuning your stress test harness 》

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