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的狀況，則說明在當前環境下，系統承受不了當前併發用戶的負載壓力，那麼最大併發用戶數就是前一個沒有出現這種現象的併發用戶數。