LoadRunner壓力測試結果分析探讨

分析原則：

　　1. 具體問題具體分析（這是由于不同的應用系統，不同的測試目的，不同的性能關注點）

　　2. 查找瓶頸時按以下順序，由易到難。

　　伺服器硬體瓶頸 網絡瓶頸（對區域網路，可以不考慮） 伺服器作業系統瓶頸（參數配置） 中間件瓶頸（參數配置，資料庫，web伺服器等） 應用瓶頸（SQL語句、資料庫設計、業務邏輯、算法等）

　　分析的資訊來源：

　　1. 根據場景運作過程中的錯誤提示資訊

　　2. 根據測試結果收集到的監控名額資料

　　一．錯誤提示分析

　　分析執行個體：

　　1．Error: Failed to connect to server “172.17.7.230″: [10060] Connection

　　Error: timed out Error: Server “172.17.7.230″ has shut down the connection prematurely

　　分析：

　　A、應用服務死掉。

　　（小使用者時：程式上的問題。程式上處理資料庫的問題，實際測試中多半是伺服器連結的配置問題）

　　B、應用服務沒有死

　　（應用服務參數設定問題）

　　對應的Apache和tomcat的最大連結數需要修改，如果連接配接時收到connection refused消息，說明應提高相應的伺服器最大連接配接的設定，增加幅度要根據實際情況和伺服器硬體的情況來定，建議每次增加25%！

　　C、資料庫的連接配接

　　(資料庫啟動的最大連接配接數（跟硬體的記憶體有關）)

　　D、我們的應用程式spring控制的最大連結數太低

　　2. Error: Page download timeout (120 seconds) has expired

　　A、應用服務參數設定太大導緻伺服器的瓶頸

　　B、頁面中圖檔太多

　　C、在程式處理表的時候檢查字段太大多

　　D、實際測試時有些資源需要請求外網，而我們的測試環境是區域網路環境

　　3. Error “http://172.17.7.230/Home.do....”

　　A、腳本設計錯誤，造成頁面異常。伺服器有響應！

　　B、并發數過大，造成伺服器響應延遲。

　　4. Error page “text=xxxxx”

　　A、腳本設計問題，例如，前一腳本修改了某些内容，造成後面的腳本通路異常。

　　B、不确定因素，有時候回放正常的腳本，一放到場景中就出現這樣的錯誤。隻能反複修改腳本！

　　二．監控名額資料分析

　　1．Vusers數

　　Loadrunner 系統設定的虛拟使用者數目。Vuser去實際調用事先制作的腳本檔案中的應用。

　　每個Vuser産生響應的操作，所有的操作對伺服器形成并發。

　　顔色 比例 度量 圖最小值 圖平均值 圖最大值 圖中間值 圖SD

　　1 Run 0.0 21.25 44 41 21.276

　　在實際測試中，Vusers可以根據實際情況的需要，在測試過程中增加或者減少。

　　2．最大并發使用者數：

　　顔色 比例 度量 最小值 平均值 最大值 SD

　　100 Apache CPU 使用情況(Apache):172.17.7.210 0.777 0.852 0.93 0.043

　　0.01 已發送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924

　　0.1 點選次數/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201

　　應用系統在目前環境下能承受的最大并發使用者數。

　　在方案運作中，如果出現了大批使用者的業務操作失敗，或出現了伺服器shutdown的情況，則說明在目前環境下，系統承受不了目前并發使用者的負載壓力，那麼最大并發使用者數就是前一個沒有出現這種現象的并發使用者數。

本文轉自 32氪 51CTO部落格，原文連結:http://blog.51cto.com/10672221/1904347