淺談loadrunner中pacing設置

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

前段時間，我在對X銀行招聘信息系統進行性能測試的時候，發現這個值的設置對於測試的結果有着很大的影響，很遺憾當時沒有深刻研究這個問題，而只是簡單地認爲它同腳本中的 thinktime 同樣只是爲了更真實地模擬實際狀況而已。最近在網絡上看到一篇題爲《調整壓力測試工具》的文章，讀完以後，再用以前個人測試經歷加以印證，真有種豁然開朗的感受。如下就將個人一些體會與你們分享：

一般咱們在談到一個軟件的「性能」的時候，首先想到的就是「響應時間」和「併發用戶數」這兩個概念。咱們看到的性能需求常常都是這樣定義的：

「要求系統支持 100 個併發用戶」

看到這樣的性能需求，咱們每每會不假思索地就在測試場景中設置 100 個用戶，讓它們同時執行某一個測試腳本，而後觀察其操做的響應時間，咱們都是這樣作的，不是嗎？我在實際實施性能測試的過程當中，也每每都是這樣作的。惋惜的是，咱們中的大多數人不多去更深刻地思考一下其中的奧妙，包括我本身。

事實上，評價一個軟件系統的性能，能夠從兩個不一樣的視角去看待：客戶端視角和服務器視角（也有人把它叫作用戶視角和系統視角），與此相對應的，又能夠引出兩個讓初學者很容易混淆的兩個概念：「併發用戶數」和「每秒請求數」。「併發用戶數」是從客戶端視角去定義的，而「每秒請求數」則是從服務器視角去定義的。

所以，上面所描述的作法的侷限性就是，它反映的僅僅是客戶端的視角。

對於這個世界上的不少事情，變換不一樣的角度去看它，每每能夠有助於咱們獲得更正確的結論。如今，咱們就轉換一下角度，以服務器的視角來看看性能需求應該怎麼樣定義：

「要求系統的事務處理能力達到 100 個 / 秒」 ( 這裏爲了理解的方便，假定在測試腳本中的一個事務僅僅包含一次請求 )

面對以這樣方式提出的性能需求，在 LoadRunner 中，咱們又該如何去設置它的併發用戶數呢？千萬不要想固然地覺得設置了 100 個併發用戶數，它就會每秒向服務器提交 100 個請求，這是兩個不一樣的概念，由於 LoadRunner 模擬客戶端向服務器發出請求，必須等待服務器對這個請求作出響應，而且客戶端收到這個響應以後，纔會從新發出新的請求，而服務器對請求的處理是須要一個時間的。咱們換個說法，對於每一個虛擬用戶來講，它對服務器發出請求的頻率將依賴於服務器對這個請求的處理時間。而服務器對請求的處理時間是不可控的，若是咱們想要在測試過程當中維持一個穩定的每秒請求數（ RPS ），只有一個方法，那就是經過增長併發用戶數的數量來達到這個目的。這個方法看起來彷佛沒有什麼問題，若是咱們在測試場景中只執行一次迭代的話。然而有經驗的朋友都會知道，實際狀況並非這樣，咱們一般會對場景設置一個持續運行時間（即屢次迭代），經過多個事務 (transaction)的取樣平均值來保證測試結果的準確性。測試場景以迭代的方式進行，若是不設置步進值的話，那麼對於每一個虛擬用戶來講，每個發到服務器的請求獲得響應以後，會立刻發送下一次請求。同時，咱們知道， LoadRunner 是以客戶端的角度來定義「響應時間」的 ，當客戶端請求發出去後，LoadRunner 就開始計算響應時間，一直到它收到服務器端的響應。這個時候問題就產生了：若是此時的服務器端的排隊隊列已滿，服務器資源正處於忙碌的狀態，那麼該請求會駐留在服務器的線程中，換句話說，這個新產生的請求並不會對服務器端產生真正的負載，但很遺憾的是，該請求的計時器已經啓動了，所以咱們很容易就能夠預見到，這個請求的響應時間會變得很長，甚至可能長到使得該請求因爲超時而失敗。等到測試結束後，咱們查看一下結果，就會發現這樣一個很不幸的現象：事務平均響應時間很長，最小響應時間與最大響應時間的差距很大，而這個時候的平均響應時間，其實也就失去了它應有的意義。也就是說，因爲客戶端發送的請求太快而致使影響了實際的測量結果。

所以，爲了解決這個問題，咱們能夠在每兩個請求之間插入一個間隔時間，這將會下降單個用戶啓動請求的速度。間歇會減小請求在線程中駐留的時間，從而提供更符合現實的響應時間。這就是我在文章開頭所提到的 Pacing 這個值的做用。

最後再補充一句話：雖然性能測試一般都是從客戶端活動的角度定義的，可是它們應該以服務器爲中心的視角來看待。請注意這句話，理解它很重要，只有真正理解了這句話，你纔會明白爲何咱們一直強調作性能測試的時候要保證一個獨立、乾淨的測試環境，以及一個穩定的網絡，由於咱們但願評價的是軟件系統真正的性能，因此必須排除其它一切因素對系統性能形成的影響。