Loadrunner性能指標分析

1、用戶事務分析

用戶事務分析是站在用戶角度進行的基礎性能分析。

1.Transation Sunmmary（事務綜述）

對事務進行綜合分析是性能分析的第一步，經過分析測試時間內用戶事務的成功與失敗狀況，能夠直接判斷出系統是否運行正常。

2.Average Transaciton Response Time（事務平均響應時間）

「事務平均響應時間」顯示的是測試場景運行期間的每一秒內事務執行所用的平均時間，經過它能夠分析測試場景運行期間應用系統的性能走向。根據該圖，能夠定位出現性能問題的轉折點。

說明：隨着測試時間的變化，系統處理事務的速度開始逐漸變慢，這說明應用系統隨着投產時間的變化，總體性能將會有降低的趨勢。

當事務響應時間的曲線開始由緩慢上升，而後處於平衡，最後慢慢降低，可能狀況：

1. 曲線圖持續上升，代表系統的處理能力在降低，事務的響應時間變長
2. 持續平衡，代表併發用戶數達到必定數量，再多請求也可能接受不了，等待
3. 當事務的響應時間在降低，代表併發用戶的數量在慢慢減小，事務的請求數也在減小。

若是系統沒有出現降低，但響應時間愈來愈長，直到系統癱瘓，引發緣由可能以下:

1. 程序中用戶數鏈接未作限制，致使請求數不斷上升，響應時間不斷變長
2. 內存泄露

3.Transactions per Second（每秒經過事務數，簡寫TPS）

「每秒經過事務數/TPS」顯示在場景運行的每一秒鐘，每一個事務經過、失敗以及中止的數量，使考查系統性能的一個重要參數。經過它能夠肯定系統在任何給定時刻的時間事務負載。分析TPS主要是看曲線的性能走向。將它與平均事務響應時間進行對比，能夠分析事務數目對執行時間的影響。

說明：當壓力加大時，點擊率/TPS曲線若是變化緩慢或者有平坦的趨勢，頗有多是服務器開始出現瓶頸。TPS值，越大說明系統處理能力越強。

4.Total Transactions per Second（每秒經過事務總數）

「每秒經過事務總數」顯示在場景運行時，在每一秒內經過的事務總數、失敗的事務總署以及中止的事務總數。該曲線走向和TPS曲線走向一致。

5.Transaction Performance Sunmmary（事務性能摘要）

「事務性能摘要」顯示方案中全部事務的最小、最大和平均執行時間，能夠直接判斷響應時間是否符合用戶的要求。

說明：重點關注事務的平均和最大執行時間，若是其範圍不在用戶能夠接受的時間範圍內，須要進行緣由分析。

6.Transaction Response Time Under Load（事務響應時間與負載）

「事務響應時間與負載」是「正在運行的虛擬用戶」圖和「平均響應事務時間」圖的組合，經過它能夠看出在任一時間點事務響應時間與用戶數目的關係，從而掌握系統在用戶併發方面的性能數據，爲擴展用戶系統提供參考。此圖能夠查看虛擬用戶負載對執行時間的整體影響，對分析具備漸變負載的測試場景比較有用。

7.Transaction Response Time(Percentile)（事務響應時間(百分比)）

「事務響應時間(百分比)」是根據測試結果進行分析而獲得的綜合分析圖，也就是工具經過一些統計分析方法間接獲得的圖表。經過它能夠分析在給定事務響應時間範圍內能執行的事務百分比。

說明：主要觀察，在給定時間的範圍內完成事務的百分比 參考值： 10%的TRT（P）

8.Transaction Response Time(Distribution)（事務響應時間(分佈)）

「事務響應時間(分佈)」顯示在場景運行過程當中，事務執行所用時間的分佈，經過它能夠了解測試過程當中不一樣響應時間的事務數量。若是系統預先定義了相關事務能夠接受的最小和最 大事務響應時間，則可使用此圖肯定服務器性能是否在能夠接受的範圍內。

說明：主要觀察，大多數事務的響應時間。 參考值：TRT（D）

2、肯定CPU、內存泄露問題

1.%processor time(processor_total)

服務器消耗的處理器時間數量.若是服務器專用於sql server 可接受的最大上限是80% -85 %.也就是常見的CPU使用率。

說明：正常負載下，服務器的CPU利用率應該在80%如下。超過90%,那麼極可能存在處理器瓶頸。若是CPU使用率不斷上升，內存使用率也不斷上升，代表系統可能產生資源爭用狀況，引發緣由，程序資源調配問題。

判斷是否內存泄露問題：

內存問題主要檢查應用程序是否存在內存泄漏,若是發生了內存泄漏，P rocess Bytes\Private Bytes計數器和Process\Working set 計數器的值每每會升高，同時Avaiable bytes的值會下降。內存泄漏應該經過一個長時間的，用來研究分析全部內存都耗盡時，應用程序反應狀況的測試來檢驗。內存泄露問題常常出如今服務長時間運轉的時候,因爲部分程序對內存沒有釋放，而將內存慢慢耗盡，也是提醒你們對系統穩定性測試的關注。

2.%Disk time(physicaldisk_total)

指所選磁盤驅動器忙於爲讀或寫入請求提供服務所用的時間的百分比。若是三個計數器都比較大，那麼硬盤不是瓶頸。若是隻有%Disk Time比較大，另外兩個都比較適中，硬盤可能會是瓶頸。在記錄該計數器以前，請在Windows 2000 的命令行窗口中運行diskperf -yD。

說明：正常值

3.Availiable bytes(memory)

用物理內存數. 若是Available Mbytes的值很小(4 MB 或更小)，則說明計算機上總的內存可能不足，或某程序沒有釋放內存。

參考值：4 MB或更小，至少要有10%的物理內存值。

4.Page write/sec

(寫的頁/秒)每秒執行的物理數據庫寫的頁數。

說明：若是服務器沒有足夠的內存處理其工做負荷，此數值將一直很高。若是大於80，表示有問題(太多的讀寫數據操做要訪問磁盤，可考慮增長內存或優化讀寫數據的算法)。

【其餘參數】

%User time(processor_total)

表示耗費CPU的數據庫操做，如排序，執行aggregate functions等。若是該值很高，可考慮增長索引，儘可能使用簡單的表聯接，水平分割大表格等方法來下降該值。

%DPC time(processor_total)

越低越好。在多處理器系統中，若是這個值大於50%而且Processor:% Processor Time很是高，加入一個網卡可能會提升性能，提供的網絡已經不飽和。

Context switch/sec(system)

(實例化inetinfo 和dllhost 進程) 若是你決定要增長線程字節池的大小，你應該監視這三個計數器(包括上面的一個)。增長線程數可能會增長上下文切換次數，這樣性能不會上升反而會降低。若是十個實例的上下文切換值很是高，就應該減少線程字節池的大小。

說明：可判斷應用程序的問題。若是系統因爲應用程序代碼效率低下或者系統結構設計有缺陷而致使大量的上下文切換(Context switches/sec顯示的上下文切換次數過高)那麼就會佔用大量的系統資源,若是系統的吞吐量下降而且CPU的使用率很高,而且此現象發生時切換水平在15000以上,那麼意味着上下文切換次數太高。

%Disk reads/sec(physicaldisk_total)

每秒讀硬盤字節數。

%Disk write/sec(physicaldisk_total)

每秒寫硬盤字節數。

Page faults/sec

進程產生的頁故障與系統產生的相比較，以判斷這個進程對系統頁故障產生的影響。

Pages per second

每秒鐘檢索的頁數。

該數字應少於每秒一頁Working set:理線程最近使用的內存頁，反映了每個進程使用的內存頁的數量。若是服務器有足夠的空閒內存，頁就會被留在工做集中，當自由內存少於一個特定的閾值時，頁就會被清除出工做集。

Avg.disk queue length

讀取和寫入請求(爲所選磁盤在實例間隔中列隊的)的平均數。該值應不超過磁盤數的1.5~2 倍。要提升性能，可增長磁盤。注意：一個Raid Disk實際有多個磁盤。

Average disk read/write queue length

指讀取(寫入)請求(列隊)的平均數Disk reads/(writes)/s:理磁盤上每秒鐘磁盤讀、寫的次數。二者相加，應小於磁盤設備最大容量。

Average disk sec/read

以秒計算的在此盤上讀取數據的所需平均時間。Average disk sec/transfer:指以秒計算的在此盤上寫入數據的所需平均時間。

Bytes total/sec

爲發送和接收字節的速率，包括幀字符在內。判斷網絡鏈接速度是不是瓶頸，能夠用該計數器的值和目前網絡的帶寬比較Page read/sec:每秒發出的物理數據庫頁讀取數。這一統計信息顯示的是在全部數據庫間的物理頁讀取總數。因爲物理 I/O 的開銷大，能夠經過使用更大的數據高速緩存、智能索引、更高效的查詢或者改變數據庫設計等方法，使開銷減到最小。

3、肯定網絡問題

1.Hits per Second（每秒點擊次數）

「每秒點擊次數」，即便運行場景過程當中虛擬用戶每秒向Web服務器提交的HTTP請求數。 經過它能夠評估虛擬用戶產生的負載量，如將其和「平均事務響應時間」圖比較，能夠查看點擊次數對事務性能產生的影響。

說明：經過對查看「每秒點擊次數」，能夠判斷系統是否穩定。系統點擊率降低一般代表服務器的響應速度在變慢，需進一步分析，發現系統瓶頸所在。

2.Throughput（吞吐率）

「吞吐率」顯示的是場景運行過程當中服務器的每秒的吞吐量。其度量單位是字節，表示虛擬用在任何給定的每一秒從服務器得到的數據量。能夠依據服務器的吞吐量來評估虛擬用戶產生的負載量，以及看出服務器在流量方面的處理能力以及是否存在瓶頸。 「吞吐率」圖，是每秒服務器處理的HTTP申請數。 「點擊率」圖，是客戶端每秒從服務器得到的總數據量。

說明：觀察3張圖（Running Vusers（負載數）/His per Second（點擊率）/Throughput(吞吐量)），隨着負載的加大，點擊率和吞吐量會隨之增大。若是系統的吞吐量隨着負載的加大出現平坦或下降而且CPU的使用率很高,而且此現象發生時切換水平在15000以上,那麼意味着上下文切換次數太高，代表網絡飽和。

3.Network Delay Time

說明：網絡延遲時間的曲線突起顯示有網絡故障。

4.Network Sub-Path Time

說明：網絡Sub-Path的時間曲線跳躍式的突起證實存在網絡故障。

4、肯定性能問題是在網絡端仍是服務端

1.Web Page Breakdown（頁面分解總圖）

「頁面分解」顯示某一具體事務在測試過程的響應狀況，進而分析相關的事務運行是否正常。能夠按下面四種方式進行進一步細分：

Download Time Breaddown（下載時間細分）

「下載時間細分」圖顯示網頁中不一樣元素的下載時間，同時還可按照下載過程把時間進行分解，用不一樣的顏色來顯示DNS解析時間、創建鏈接時間、第一次緩衝時間等各自所佔比例。

Component Breakdown(Over Time)（組件細分(隨時間變化)）

「組件細分」圖顯示選定網頁的頁面組件隨時間變化的細分圖。經過該圖能夠很容易的看出哪些元素在測試過程當中下載時間不穩定。該圖特別適用於須要在客戶端下載控件較多的頁面，經過分析控件的響應時間，很容易就能發現那些控件不穩定或者比較耗時。

Download Time Breakdown(Over Time)（下載時間細分(隨時間變化)）

「下載時間細分(隨時間變化)」 圖顯示選定網頁的頁面元素下載時間細分（隨時間變化）狀況，它很是清晰地顯示了頁面各個元素在壓力測試過程當中的下載狀況。

「下載時間細分」圖顯示的是整個測試過程頁面元素響應的時間統計分析結果，「下載時間細分(隨時間變化)」顯示的事場景運行過程當中每一秒內頁面元素響應時間的統計結果，二者分別從宏觀和微觀角度來分析頁面元素的下載時間。

Time to First Buffer Breakdown(Over Time)（第一次緩衝時間細分(隨時間變化)）

「第一次緩衝時間細分(隨時間變化)」圖顯示成功收到從Web服務器返回的第一次緩衝以前的這段時間，場景或會話步驟運行的每一秒中每一個網頁組件的服務器時間和網絡時間（以秒爲單位）。可使用該圖肯定場景或會話步驟運行期間服務器或網絡出現問題的時間。

First Buffer Time：是指客戶端與服務器端創建鏈接後，從服務器發送第一個數據包開始計時，數據通過網絡傳送到客戶端，到瀏覽器接收到第一個緩衝所用的時間。

2.Page Component Breakdown（頁面組件細分）

「頁面組件細分」圖顯示每一個網頁及其組件的平均下載時間（以秒爲單位）。能夠根據下載組件所用的平均秒數對圖列進行排序，經過它有助於隔離有問題的組件。

3.Page Component Breakdown(Over Time)（頁面組件分解(隨時間變化)）

「頁面組件分解(隨時間變化)」圖顯示在方案運行期間的每一秒內每一個網頁及其組件的平均響應時間 （以秒爲單位）。

4.Page Download Time Breakdown（頁面下載時間細分）

「頁面下載時間細分」圖顯示每一個頁面組件下載時間的細分，能夠根據它肯定在網頁下載期間事務響應時間緩慢是由網絡錯誤引發仍是由服務器錯誤引發。

「頁面下載時間細分」圖根據DNS解析時間、鏈接時間、第一次緩衝時間、SSL握手時間、接收時間、FTP驗證時間、客戶端時間和錯誤時間來對每一個組件的下載過程進行細分。

5.Page Download Time Breakdown(Over Time)（頁面下載時間細分(隨時間變化)）

「頁面下載時間細分(隨時間變化)」圖顯示方案運行期間，每一秒內每一個頁面組件下載時間的細分。使用此圖能夠肯定網絡或服務器在方案執行期間哪一時間點發生了問題。 「頁面組件細分(隨時間變化)」圖和「頁面下載時間細分(隨時間變化)」圖一般結合起來進行分析：首先肯定有問題的組件，而後分析它們的下載過程，進而定位緣由在哪裏。

6.Time to First Buffer Breakdown（第一次緩衝時間細分）

「第一次緩衝時間細分」圖顯示成功收到從Web服務器返回的第一次緩衝以前的這一段時間內的每一個頁面組件的相關服務器/網路時間。若是組件的下載時間很長，則可使用此圖肯定產生的問題與服務器有關仍是與網絡有關。

網絡時間：定義爲第一個HTTP請求那一刻開始，直到確認爲止所通過的平均時間。 服務器時間：定義爲從收到初始HTTP請求確認開始，直到成功收到來自Web服務器的一次緩衝爲止所通過的平均時間。

說明：找出下載耗費時間最多的網頁。有助排出DNS的故障，SSL的故障，網絡鏈接的故障。 【其餘Web資源分析】

1.HTTP Status Code Summary（HTTP狀態代碼概要）

「HTTP狀態代碼概要」顯示場景或會話步驟過程當中從Web服務器返回的HTTP狀態代碼數，該圖按照代碼分組。HTTP狀態代碼表示HTTP請求的狀態。

2.HTTP Responses per Second（每秒HTTP響應數）

「每秒HTTP響應數」是顯示運行場景過程當中每秒從Web服務器返回的不一樣HTTP狀態代碼的數量，還能返回其它各種狀態碼的信息，經過分析狀態碼，能夠判斷服務器在壓力下的運行狀況，也能夠經過對圖中顯示的結果進行分組，進而定位生成錯誤的代碼腳本。

3.Pages Downloader per Second（每秒下載頁面數）

「每秒下載頁面數」顯示場景或會話步驟運行的每一秒內從服務器下載的網頁數。使用此圖可依據下載的頁數來計算Vuser生成的負載量。

和吞吐量圖同樣，每秒下載頁面數圖標是Vuser在給定的任一秒內從服務器接收到的數據量。可是吞吐量考慮的各個資源極其大小（例，每一個GIF文件的大小、每一個網頁的大小）。而每秒下載頁面數只考慮頁面數。

注：要查看每秒下載頁數圖，必須在R-T-S那裏設置「每秒頁面數(僅HTML模式)」。

4.Retries per Second（每秒重試次數）

「每秒重試次數」顯示場景或會話步驟運行的每一秒內服務器嘗試的鏈接次數。 在下列狀況將重試服務器鏈接： A、初始鏈接未經受權 B、要求代理服務器身份驗證 C、服務器關閉了初始鏈接 D、初始鏈接沒法鏈接到服務器 E、服務器最初沒法解析負載生成器的IP地址

5.Retries Summary（重試次數概要）

「重試次數概要」顯示場景或會話步驟運行過程當中服務器嘗試的鏈接次數，它按照重試緣由分組。將此圖與每秒重試次數圖一塊兒使用能夠肯定場景或會話步驟運行過程當中服務器在哪一個時間點進行了重試。

6.Connections（鏈接數）

「鏈接數」顯示場景或會話步驟運行過程當中每一個時間點打開的TCP/IP鏈接數。 藉助此圖，能夠知道什麼時候須要添加其餘鏈接。

說明：當鏈接數到達穩定狀態而事務響應時間迅速增大時，添加鏈接可使性能獲得極大提升（事務響應時間將下降）。

7.Connections Per Second（每秒鏈接數）

「每秒鏈接數」顯示方案在運行過程當中每秒創建的TCP/IP鏈接數。 理想狀況下，不少HTTP請求都應該使用同一鏈接，而不是每一個請求都新打開一個鏈接。經過每秒鏈接數圖能夠看出服務器的處理狀況，就代表服務器的性能在逐漸降低。

8.SSLs Per Second（每秒SSL鏈接數）

「每秒SSL鏈接數」顯示場景或會話步驟運行的每一秒內打開的新的以及從新使用的SSL鏈接數。當對安全服務器打開TCP/IP鏈接後，瀏覽器將打開SSL鏈接。

9.Web Page Breakdown（網頁元素細分）

「網頁元素細分」主要用來評估頁面內容是否影響事務的響應時間，經過它能夠深刻地分析網站上那些下載很慢的圖形或中斷的鏈接等有問題的 元素。

10.Time to First Buffer Breakdown(Over Time)（第一次緩衝時間細分(隨時間變化)）

「第一次緩衝時間細分(隨時間變化)」圖顯示成功收到從Web服務器返回的第一個緩衝以前的這段時間內，場景運行的每一秒中每一個網頁組件的服務器時間和網絡時間。可使用此圖肯定場景運行期間服務器或網絡出現問題的時間點。

11.Downloader Component Size(KB)（已下載組件大小）

「已下載組件大小」圖顯示每一個已經下載的網頁組建的大小。經過它能夠直接看出哪些組件比較大並須要進一步進行優化以提升性能。