用LoadRunner進行壓力測試

LoadRunner工具介紹

LoadRunner是一種自動負載測試工具，它通過模擬用戶實施并發負載、實時性能監測的方式來確認和查找問題，優化性能和加速應用系統的發布周期。

LoadRunner主要由虛擬用戶發生器(VuGen)、壓力控制器（Controller）、壓力產生器（Load Generator）和結果分析工具(Analysis)組成，架構圖如圖1。

1.虛擬用戶發生器(VuGen)實際上是一個集成開發環境，用于錄制和編輯虛擬用戶腳本的工具。

2.壓力控制器（Controller）是一個框架程序和監控程序,負責將VuGen開發的腳本以多進程的方式在Load Generator機器上運行。

圖1 LoadRunner工具架構圖

3.壓力產生器（Load Generator）是扮演產生負載的角色，根據腳本內容，產生實際的負載。

4.壓力結果分析工具(Analysis)是一個數據分析工具, 用于測試后的結果分析。

5.用戶確定要進行測試的業務,通過用戶操作和VuGen的錄制功能來記錄并生成虛擬用戶腳本。手工修改虛擬用戶腳本,并確定腳本可以回放成功。在Controller中對場景進行配置,啟動測試。

在測試過程中，Controller控制Load Generator對被測系統的加壓方式和行為，同時負責搜集被測系統各個環節的性能數據，而各個Load Generator會記錄最終用戶的響應時間和腳本執行日志。

壓力運行結束后，Load Generator將數據傳送到Controller中，由Controller對測試結果進行匯總。測試人員借助Analysis對性能測試數據進行分析，進而確定瓶頸和調優方案。對系統進行調優，重復負載測試過程，直至符合系統性能要求。

壓力測試的常見問題

問題1：信息系統的訪問量急劇增長，當訪問量達到一個閾值時，系統性能急劇下降，此時訪問量與系統性能之間的關系是非線性的，這個閾值難以預測。

問題2：信息系統始終是處于變化中，不斷的變化又會產生其他風險，IT人員缺乏對這些風險的預測能力。

問題3：業務應用是由許多事務構成，我們經常需要以事務為單元對系統性能進行監測。

比如，電商平臺上，用戶購買商品的整個操作過程就是一個事務。每個事務包含一連串的用戶動作，雖然這些動作高度相關，但是這些動作關聯在一起后，對性能的影響卻難以量化。

問題4：信息系統種類多，系統性能受多種因素影響，包括軟件代碼效率、系統穩定性、服務器性能、網絡性能等等，如何精確配置系統，使系統性能滿足業務需求，粗略估計的方法顯然存在很大風險。

下面我們以模擬的辦公自動化（OA）系統為環境，以LoadRunner為工具，介紹壓力測試的方法。

測試內容及流程方法

測試內容

測試內容主要是：服務器是否能承受現有的系統負載；業務的極限負載。

圖2 錄制結果

規劃負載測試

1.系統環境

為了便于演示和分析，整個測試環境均在一臺服務器上完成：利用虛擬機在實體服務器上搭建OA系統；在實體服務器上安裝LoadRunner；網絡環境為虛擬的星形結構，OA系統為中心，對外提供服務，模擬用戶采用百兆局域網訪問OA系統。

圖3 場景控制

2.系統負載

系統主要提供基于網頁的OA服務，最大用戶數50左右。

3.創建測試腳本

LoadRunner測試腳本可以通過行為錄制的方式進行創建。錄制過程中，LoadRunner將會記錄所有用戶操作和系統響應，記錄的結果是腳本，通過對腳本的編輯可以實現批量化、個性化的參數修改。例如，在用戶登錄過程中，通過腳本讀取參數，能實現自動以不同的用戶身份登錄系統，這樣就能使模擬行為更加真實，如圖2所示。

4.創建負載測試場景

LoadRunner通過場景來模擬用戶的實際環境。在場景中，可以添加多個腳本，我們添加剛才錄制的腳本后開始創建場景，如圖3。

在圖中左上角為“場景組”編輯區，可以在這里對負載進行調整。按照本部門服務器的負載情況，我們添加50個虛擬用戶。

用戶數是比較簡單的場景設置，除此之外，我們還可以設置更為復雜的場景，使測試場景和實際環境盡可能一致。

比如，可以安排向系統施加負載的時間（因為用戶不會正好同時登錄或退出系統）；使用不同類型的瀏覽器 （例如360、谷歌、搜狗等瀏覽器）來瀏覽網頁；使用不同的網絡連接（例如局域網、光纖或E1專線），這些復雜的模擬都可以在場景實現。

5.運行負載測試

設置好場景后，可以開始負載測試。根據場景設置，每15秒新增兩個用戶在線，逐漸增加負載，LoadRunner將記錄下系統的各個指標，如圖4。

運行結束后，總共產生了89個失敗的事務，1149個系統錯誤，下面就對這些錯誤進行分析。

圖4 負載測試運行結束

圖5 用戶-錯誤組合圖

圖6 用戶-資源組合圖

6.分析測試結果

在運行過程中，出現錯誤。為了找到錯誤原因，我們利用結果分析功能對測試進行分析。系統出現錯誤是在負載不斷增加的情況下產生的，首先看系統在何時出現錯誤，通過截取組合圖來查找原因，圖5是每秒錯誤數與用戶數的關系組合圖。

圖5中每秒錯誤數曲線在5:20時開始出現錯誤（此時用戶數也在40左右），到6:24時錯誤達到最高峰。

通過圖5可以初步判斷，OA系統用戶數的極限基本在40左右。超過40用戶數，系統將會產生大量錯誤。

雖然得出系統極限用戶數，但這還不足以為改善系統提供參考。我們希望可以定位系統出現錯誤的原因，找到系統瓶頸。

先看服務器性能在測試中的表現，查看是否因為服務器資源不夠，導致負載增加后，出現錯誤。圖6是用戶數與系統資源的組合圖。

從圖形來看，在服務器資源中的幾十項指標中，隨著負載的增長，并沒有指標變得特別差或者波動較大。因此，可以確定在50用戶數的負載下，服務器的性能表現并沒有出現瓶頸，產生錯誤的原因不是OA服務器系統資源的不足。

再看一下產生的錯誤能否給我們提供一些參考信息。LoadRunner的錯誤報告提示了以下三種錯誤信息：

Action.c(130):錯誤-27796:連接服務器“1080 端口”失敗:“[10061]連接被拒絕”

Action.c(4):錯 誤-27792:將數據傳輸到網絡失敗: “[10054]對等端已重置連接”

Action.c(4):錯 誤-27791:服務器已過早關閉連接

從錯誤信息可以看到，錯誤信息都是關于網絡連接的，大量的連接請求被拒絕、重置和關閉。從連接錯誤這條線索，我們考慮另一個因素對系統性能的影響：網絡性能。網絡性能的好壞一般用吞吐量來衡量，在服務器資源沒有明顯變差的前提下，吞吐量基本上可以代表網絡狀況，圖7為用戶數與吞吐量的組合圖。

圖7 用戶-吞吐量組合圖

可以看到，用戶數在40以前，吞吐量與用戶數基本是線性相關的，但是當用戶數到達40左右時，系統吞吐量開始變得不穩定。吞吐量表征的是網絡性能，如果隨著時間的推移和用戶數目的增加，吞吐量不斷增加，說明帶寬夠用；如果隨著用戶數目的增加，吞吐量達到網絡性能極限后，并沒有繼續增長，而是出現較大波動，某些情況下反而出現吞吐量極低的情況，這主要是因為網絡性能達到極限，出現網絡擁塞后，網絡性能大幅下降引起。對于系統來說，網絡出現擁塞，用戶發起的許多請求就會超時，產生大量錯誤。

模擬環境下，OA服務器和LoadRunner測試環境均在同一實體終端下，測試過程中的數據收發都是通過實體終端的網卡完成，所以容易造成網絡擁塞。筆者認為如果將LoadRunner測試環境安裝在另外一臺實體終端，將較好的解決網絡擁塞的問題。

7.驗證

通過以上的原因分析，我們推斷系統整體的性能瓶頸在于網絡資源不足。為了驗證這個推斷，我們將LoadRunner測試環境安裝到局域網內的另一臺實體終端上進行測試，測試結果證實了筆者的猜想。

總結

通過以上簡單的測試過程，我們就容易得出兩個結論：

結論1：模擬環境下OA系統的極限用戶數為同時40用戶在線操作。

結論2：OA系統性能的瓶頸在于網絡性能。具體來說，根據錯誤提示可以知道，如果要提升性能，首先應該提高網絡帶寬。

以上案例是一個比較典型的壓力測試。在我們的信息系統中，還有很多類似的系統在業務化之前基本沒有經過專業的、定量化的測評，都是憑借我們長期工作中的經驗進行評估，系統上線運行后風險較大。

我們研究利用LoadRunner進行系統壓力測試和評估，尋找性能瓶頸、預測性能極限，這在信息化建設中是一項基礎性的工作，做好這項工作將使信息系統的開發和運營更加科學和規范。