LoadRunner壓力測試結果分析探討【轉載】

LoadRunner壓力測試結果分析探討

分析原則: mysql

  1. 具體問題具體分析(這是因爲不一樣的應用系統,不一樣的 測試 目的,不一樣的性能關注點) web

  2. 查找瓶頸時按如下順序,由易到難。 算法

  服務器硬件瓶頸  網絡瓶頸(對局域網,能夠不考慮)  服務器 操做系統 瓶頸(參數配置)  中間件瓶頸(參數配置, 數據庫  web 服務器等)  應用瓶頸( SQL 語句、數據庫設計、業務邏輯、算法等) spring

  分析的信息來源: sql

  1. 根據場景運行過程當中的錯誤提示信息 數據庫

  2. 根據測試結果收集到的監控指標數據 apache

  一.錯誤提示分析 緩存

  分析實例: tomcat

  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

  分析:

LoadRunner壓力測試結果分析探討

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

  從上圖能夠看出:在測試運行到4個小時左右的時候,apache的點擊數/秒開始迅速增長!

3.業務操做響應時間:

  使用「事務性能摘要」圖,能夠肯定在方案執行期間響應時間過長的事務。

  顏色 比例 度量

  1 最小值

  1 平均值

  1 最大值

  分析事務的響應狀況,要每次詳細分析,目前還只能觀察到響應時間過長的事務!

  4.每秒點擊數

  負載測試期間每秒內 Vuser 在 Web 服務器上點擊的次數。可根據點擊次數來估算 Vuser 生成的負載數。

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

  1 點擊次數 69.908 105.736 130.244 103.666 12.186

  從圖中不難看出,在4小時的時候,點技數明顯增高。和apache的每秒點擊數增大的時間相吻合!

  5.吞吐量

  負載測試期間 Web 服務器上的吞吐量(字節)。吞吐量表示在任何指定秒內 Vuser 從服務器接收到的數據量。此圖可估計 Vuser 生成的負載量(服務器吞吐量)。

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

  1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473

  一樣,從圖中能夠看出,在4個小時的時候,web服務器的吞吐量開始增高。在圖中還能夠看到吞吐量的走勢圖,從開始到進行到4個小時反彈以前呈下降的趨勢,這是由於系統在初期調用的資源都是直接來之服務器,運行一段時間後系統的部分資源來自緩存。

  6.下載組件大小

  每一個頁面的組件大小,且包括組件的標頭的大小!

  頁面組件大小的分析表格比較複雜,實際分析中能夠經過loadrunner的報告分析工具來分析。頁面組件大小分析主要是找到頁面中比較龐大的組件,若是其影響到了頁面的下載速度,則要想辦法將其改小!

  7.Apache資源

  顯示APACHE web服務器上的資源摘要。前面已經提到過以併發點擊數爲主。

  顏色 比例 度量 最小值 平均值 最大值 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

  三.服務器資源監控指標:

  (目前經過top監察)

  內存:

  Linux 資源監控中指標內存頁交換速率(Paging rate),若是該值偶爾走高,代表當時有線程競爭內存。若是持續很高,則內存多是瓶頸。也多是內存訪問命中率低。

  實際測試中,當併發點擊數出現忽然劇增先後,內存的PR 值則居高25不下。說明目前測試的系統中內存存在瓶頸!

  內存資源成爲系統性能的瓶頸的徵兆:

  很高的換頁率(high pageout rate);

  進程進入不活動狀態;

  交換區全部磁盤的活動次數可高;

  可高的全局系統CPU利用率;

  內存不夠出錯(out of memory errors)

  處理器:

  Linux資源監控中指標CPU佔用率持續超過80%(對該值的要求,根據具體應用和機器配置而要求不一樣,有資料代表95%),代表瓶頸是CPU。

  實際測試中,當併發點技數出現忽然增長先後,cpu的佔用率持續保持在86%以上!

  說明,目前系統用應用的cpu也是測試的瓶頸!

  CPU資源成爲系統性能的瓶頸的徵兆:

  很慢的響應時間(slow response time)

  CPU空閒時間爲零(zero percent idle CPU)

  太高的用戶佔用CPU時間(high percent user CPU)

  太高的系統佔用CPU時間(high percent system CPU)

  長時間的有很長的運行進程隊列(large run queue size sustained over time)

  四.數據庫服務器:

  數據庫服務器目前測試觀察,當web服務器點擊率增大時,觀察mysql數據庫的最大鏈接數,仍未超過系統設置的最大鏈接數。因此,暫時未發現數據庫的瓶頸!

  五.結論

  以上報告分析中的數據、圖標均來自同一次測試。是在平時測試中挑出的一次現象比較明顯,比較利於觀察的做爲分析案例。

  根據以上綜合分析,當前測試環境下,當應用系統產生最大533.667的併發壓力。平均負載壓力114.352。根據分析,用戶在4個小時的時 候,併發數迅速增長先後的值在400左右!分析結果跟實際測試的硬件環境以及測試腳本有必定關係。同時,測試服務器的硬件配置和實際服務器的配置還有必定 的差距!

相關文章
相關標籤/搜索