Loadrunner效能指標分析
一、使用者事務分析
使用者事務分析是站在使用者角度進行的基礎效能分析。
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)<=5s、50%的TRT(P)<=5s、90%的TRT(P)<=5s
8、Transaction Response Time(Distribution)(事務響應時間(分佈))
“事務響應時間(分佈)”顯示在場景執行過程中,事務執行所用時間的分佈,通過它可以瞭解測試過程中不同響應時間的事務數量。如果系統預先定義了相關事務可以接受的最小和最
大事務響應時間,則可以使用此圖確定伺服器效能是否在可以接受的範圍內。
說明:主要觀察,大多數事務的響應時間
參考值:TRT(D)<=5s
二、確定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。
說明:正常值<10。若數值持續超過80%,則可能是記憶體洩漏。
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 的開銷大,可以通過使用更大的資料快取記憶體、智慧索引、更高效的查詢或者改變資料庫設計等方法,使開銷減到最小。
三、確定網路問題:
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的時間曲線跳躍式的突起證明存在網路故障。
四、確定效能問題是在網路端還是服務端:
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)(已下載元件大小)
“已下載元件大小”圖顯示每個已經下載的網頁組建的大小。通過它可以直接看出哪些元件比較大並需要進一步進行優化以提高效能。
相關文章
- LoadRunner監控Unix、Windows方法及常用效能指標Windows指標
- 效能指標指標
- MySQL常用效能指標MySql指標
- PLC的7大效能指標指標
- 軟體中的效能指標指標
- Linux 網路效能指標Linux指標
- linux cpu相關效能指標Linux指標
- 伺服器效能指標(三)——記憶體使用分析及問題排查伺服器指標記憶體
- 伺服器效能指標(一)——負載(Load)分析及問題排查伺服器指標負載
- 效能測試之常見效能指標指標
- 【網路】效能指標與測試工具指標
- 剖析HBase負載均衡和效能指標負載指標
- chrome效能指標(TTFB,TTSR,TTDC,TTFL)Chrome指標TTS
- 計算機網路的效能指標計算機網路指標
- LoadRunner——分析圖詳解(十四)
- 前端頁面效能指標與採集方式前端指標
- 深度剖析HBase負載均衡和效能指標負載指標
- LoadRunner測試結果分析(1)
- Loadrunner常用15種的分析點
- .NET必知的EventCounters效能指標監視器指標
- Go之獲取系統效能指標 - goPsutilGo指標
- 以使用者為中心的效能指標【譯】指標
- MYSQL常用的效能指標總結和歸納MySql指標
- 嵌入式audio基礎(四)效能指標指標
- 核心路由器十項效能指標(轉)路由器指標
- LoadRunner常見測試結果分析
- 大話效能測試系列(3)- 常用的效能指標指標
- 為什麼我總和效能指標相差很遠?指標
- 618搞機-選購硬碟看重哪些效能指標?硬碟指標
- PostgreSQL類微博FEED系統-設計與效能指標SQL指標
- AIX 作業系統調優 效能指標祥解AI作業系統指標
- web前端應用應該關注哪些效能指標?Web前端指標
- web前端應用效能指標測量工具有哪些?Web前端指標
- C++ 只能指標迴圈引用簡單測試C++指標
- Linux作業系統效能指標監控與通知Linux作業系統指標
- 嵌入式audio基礎(五)效能指標補遺指標
- 將警告閾值和警報用於映象效能指標指標
- web前端應用效能指標最佳化方案有哪些?Web前端指標