1.前言：
LoadRunner 最重要也是最難理解的地方--測試結(jié)果的分析.其余的錄制和加壓測試等設(shè)置對于我們來講通過幾次操作就可以輕松掌握了.針對 Results Analysis 我用圖片加文字做了一個(gè)例子，希望通過例子能給大家更多的幫助.這個(gè)例子主要講述的是多個(gè)用戶同時(shí)接管任務(wù)，測試系統(tǒng)的響應(yīng)能力，確定系統(tǒng)瓶頸所在.客戶要求響應(yīng)時(shí)間是1 個(gè)人接管的時(shí)間在5S 內(nèi).
2.系統(tǒng)資源：
2.1 硬件環(huán)境：
CPU：奔四2.8E
硬盤：100G
網(wǎng)絡(luò)環(huán)境：100Mbps
2.2 軟件環(huán)境：
操作系統(tǒng)：英文windowsXP
服務(wù)器：tomcat 服務(wù)
瀏覽器：IE6.0
系統(tǒng)結(jié)構(gòu)：B/S 結(jié)構(gòu)
3.添加監(jiān)視資源
下面要講述的例子添加了我們平常測試中最常用到的一些資源參數(shù).另外有些特殊的資源暫時(shí)在這里不做講解了.我會(huì)在以后相繼補(bǔ)充進(jìn)來。
Mercury Loadrunner Analysis 中最常用的5 種資源.
1. Vuser
2. Transactions
3. Web Resources
4. Web Page Breakdown
5. System Resources
在Analysis 中選擇“Add graph”或“New graph”就可以看到這幾個(gè)資源了.還有其他沒有數(shù)據(jù)的資源，我們沒有讓它顯示.
如果想查看更多的資源，可以將左下角的display only graphs containing data 置為不選.然后選中相應(yīng)的點(diǎn)“open graph”即可.
打開Analysis 首先可以看的是Summary Report.這里顯示了測試的分析摘要.應(yīng)有盡有.但是我們并不需要每個(gè)都要仔細(xì)去看.下面介紹一下部分的含義：
Duration(持續(xù)時(shí)間)：了解該測試過程持續(xù)時(shí)間.測試人員本身要對這個(gè)時(shí)期內(nèi)系統(tǒng)一共做了多少的事有大致的熟悉了解.以確定下次增加更多的任務(wù)條件下測試的持續(xù)時(shí)間。
Statistics Summary(統(tǒng)計(jì)摘要)：只是大概了解一下測試數(shù)據(jù)，對我們具體分析沒有太大的作用.
Transaction Summary(事務(wù)摘要)：了解平均響應(yīng)時(shí)間Average單位為秒.
其余的看不看都可以.都不是很重要.
【注】 51Testing授權(quán)IT168獨(dú)家轉(zhuǎn)載，未經(jīng)明確的書面許可，任何人或單位不得對本文內(nèi)容復(fù)制、轉(zhuǎn)載或進(jìn)行鏡像，否則將追究法律責(zé)任。
內(nèi)容導(dǎo)航
4.分析集合點(diǎn)
在錄制腳本中通常我們會(huì)使用到集合點(diǎn)，那么既然我們用到了集合點(diǎn)，我們就需要知道Vuser 是在什么時(shí)候集合在這個(gè)點(diǎn)上，又是怎樣的一個(gè)被釋放的過程.這個(gè)時(shí)候就需要觀察Vuser-Rendezvous 圖.
圖1
可以看到大概在3 分50 的地方30 個(gè)用戶才全部集中到start 集合點(diǎn)，持續(xù)了3 分多，在7 分30 的位置開始釋放用戶，9 分30 還有18 個(gè)用戶，11 分10 還有5 個(gè)用戶，整個(gè)過程持續(xù)了12 分.
圖2
上面圖2 是集合點(diǎn)與平均事務(wù)響應(yīng)時(shí)間的比較圖.
注:在打開analysis 之后系統(tǒng)LR 默認(rèn)這兩個(gè)曲線是不在同一張圖中的.這就需要自行設(shè)置了.具體步驟如下:
點(diǎn)擊圖上.右鍵選擇merge graphs.然后在select graph to merge with 中選擇即將用來進(jìn)行比較的graph.如圖3:
圖3
圖2 中較深顏色的是平均響應(yīng)時(shí)間，淺色的為集合點(diǎn)，當(dāng)Vuser 在集合點(diǎn)持續(xù)了1分后平均響應(yīng)時(shí)間呈現(xiàn)最大值，可見用戶的并發(fā)對系統(tǒng)的性能是一個(gè)很大的考驗(yàn).接下來看一下與事務(wù)有關(guān)的參數(shù)分析.下看一張圖.
圖4
這張圖包括Average Transaction Response Time 和Running Vuser 兩個(gè)數(shù)據(jù)圖.從圖中可以看到Vuser_init_Transaction(系統(tǒng)登錄)對系統(tǒng)無任何的影響，Vuser 達(dá)到15 個(gè)的時(shí)候平均事務(wù)響應(yīng)時(shí)間才有明顯的升高，也就是說系統(tǒng)達(dá)到最優(yōu)性能的時(shí)候允許14 個(gè)用戶同時(shí)處理事務(wù)，Vuser 達(dá)到30 后1 分，系統(tǒng)響應(yīng)時(shí)間最大，那么這個(gè)最大響應(yīng)時(shí)間是要推遲1 分鐘才出現(xiàn)的，在系統(tǒng)穩(wěn)定之后事務(wù)響應(yīng)時(shí)間開始下降說明這個(gè)時(shí)候有些用戶已經(jīng)執(zhí)行完了操作.同時(shí)也可以看出要想將事務(wù)響應(yīng)時(shí)間控制在10S 內(nèi).Vuser 數(shù)量最多不能超過2 個(gè).看來是很難滿足用戶的需求了.
做一件事有時(shí)候上級會(huì)問你這件事辦得怎么樣了.你會(huì)說做完一半了.那么這個(gè)一半的事情你花了多少時(shí)間呢？所以我們要想知道在給定時(shí)間的范圍內(nèi)完成事務(wù)的百分比就要靠下面這個(gè)圖(Transaction Response Time(Percentile)
圖中畫圈的地方表示10%的事務(wù)的響應(yīng)時(shí)間是在80S 左右.80S 對于用戶來說不是一個(gè)很小的數(shù)字，而且只有10%的事務(wù)，汗.你覺得這個(gè)系統(tǒng)性能會(huì)好么！
實(shí)際工作中遇到的事情不是每一件事都能夠在很短的時(shí)間內(nèi)完成的，對于那些需要時(shí)間的事情我們就要分配適當(dāng)?shù)臅r(shí)間處理，時(shí)間分配的不均勻就會(huì)出現(xiàn)有些事情消耗的時(shí)間長一些，有些事情消耗的短一些，但我們自己清楚.LR 同樣也為我們提供了這樣的功能，使我們可以了解大部分的事務(wù)響應(yīng)時(shí)間是多少？以確定這個(gè)系統(tǒng)我們還要付出多少的代價(jià)來提高它.
Transaction Response Time(Distribution)-事務(wù)響應(yīng)時(shí)間(分布)
顯示在方案中執(zhí)行事務(wù)所用時(shí)間的分布.如果定義了可以接受的最小和最大事務(wù)性能時(shí)間，可以通過此圖確定服務(wù)器性能是否在可接受范圍內(nèi).
很明顯大多數(shù)事務(wù)的響應(yīng)時(shí)間在60-140S.在我測試過的項(xiàng)目中多數(shù)客戶所能接受的最大響應(yīng)時(shí)間也要在20S 左右.140S 的時(shí)間！很少有人會(huì)去花這么多的時(shí)間去等待頁面的出現(xiàn)吧！
通過觀察以上的數(shù)據(jù)表.我們不難看到此系統(tǒng)在這種環(huán)境下并不理想.世間事有果就有因，那么是什么原因?qū)е碌孟到y(tǒng)性能這樣差呢？讓我們一步一步的分析.
系統(tǒng)性能不好的原因多方面，我們先從應(yīng)用程序看.有的時(shí)候我不得不承認(rèn)LR 的功能真的很強(qiáng)大，這也是我喜歡它的原因.先看一張頁面細(xì)分圖.
一個(gè)應(yīng)用程序是由很多個(gè)組件組成的，整個(gè)系統(tǒng)性能不好那我們就把它徹底的剖析一下.圖片中顯示了整個(gè)測試過程中涉及到的所有web 頁.web page breakdown中顯示的是每個(gè)頁面的下載時(shí)間.點(diǎn)選左下角web page breakdown 展開，可以看到每個(gè)頁中包括的css 樣式表，js 腳本，jsp 頁面等所有的屬性
在select page to breakdown 中選擇頁面.
見圖.
在 Select Page To Breakdown 中選擇http：//192.168.0.135：8888/usertasks 后，在下方看到屬于它的兩個(gè)組件，第一行中Connection 和First Buffer 占據(jù)了整個(gè)的時(shí)間，那么它的消耗時(shí)間點(diǎn)就在這里，我們解決問題就要從這里下手.
也有可能你的程序中client 的時(shí)間最長.或者其他的，這些就要根據(jù)你自己的測試結(jié)果來分析了.下面我們來看一下CPU，內(nèi)存.硬盤的瓶頸分析方法：
首先我們要監(jiān)視CPU，內(nèi)存.硬盤的資源情況.得到以下的參數(shù)提供分析的依據(jù).
%processor time(processor_total)：器消耗的處理器時(shí)間數(shù)量.如果服務(wù)器專用于sql server 可接受的最大上限是80% -85 %.也就是常見的CPU 使用率.
%User time(processor_total)：：表示耗費(fèi)CPU的數(shù)據(jù)庫操作，如排序，執(zhí)行aggregate functions等。如果該值很高，可考慮增加索引，盡量使用簡單的表聯(lián)接，水平分割大表格等方法來降低該值。
%DPC time(processor_total)：：越低越好。在多處理器系統(tǒng)中，如果這個(gè)值大于50%并且Processor：% Processor Time非常高，加入一個(gè)網(wǎng)卡可能會(huì)提高性能，提供的網(wǎng)絡(luò)已經(jīng)不飽和。
%Disk time(physicaldisk_total)：指所選磁盤驅(qū)動(dòng)器忙于為讀或?qū)懭胝埱筇峁┓?wù)所用的時(shí)間的百分比。如果三個(gè)計(jì)數(shù)器都比較大，那么硬盤不是瓶頸。如果只有%Disk Time比較大，另外兩個(gè)都比較適中，硬盤可能會(huì)是瓶頸。在記錄該計(jì)數(shù)器之前，請?jiān)赪indows 2000 的命令行窗口中運(yùn)行diskperf -yD。若數(shù)值持續(xù)超過80%，則可能是內(nèi)存泄漏。
Availiable bytes(memory)：用物理內(nèi)存數(shù). 如果Available Mbytes的值很小(4 MB 或更小)，則說明計(jì)算機(jī)上總的內(nèi)存可能不足，或某程序沒有釋放內(nèi)存。
Context switch/sec(system)： (實(shí)例化inetinfo 和dllhost 進(jìn)程) 如果你決定要增加線程字節(jié)池的大小，你應(yīng)該監(jiān)視這三個(gè)計(jì)數(shù)器(包括上面的一個(gè))。增加線程數(shù)可能會(huì)增加上下文切換次數(shù)，這樣性能不會(huì)上升反而會(huì)下降。如果十個(gè)實(shí)例的上下文切換值非常高，就應(yīng)該減小線程字節(jié)池的大小。
%Disk reads/sec(physicaldisk_total)：每秒讀硬盤字節(jié)數(shù).
%Disk write/sec(physicaldisk_total)：每秒寫硬盤字節(jié)數(shù).
Page faults/sec：進(jìn)程產(chǎn)生的頁故障與系統(tǒng)產(chǎn)生的相比較，以判斷這個(gè)進(jìn)程對系統(tǒng)頁故障產(chǎn)生的影響。
Pages per second：每秒鐘檢索的頁數(shù)。該數(shù)字應(yīng)少于每秒一頁Working set：理線程最近使用的內(nèi)存頁，反映了每一個(gè)進(jìn)程使用的內(nèi)存頁的數(shù)量。如果服務(wù)器有足夠的空閑內(nèi)存，頁就會(huì)被留在工作集中，當(dāng)自由內(nèi)存少于一個(gè)特定的閾值時(shí)，頁就會(huì)被清除出工作集。
Avg.disk queue length：讀取和寫入請求(為所選磁盤在實(shí)例間隔中列隊(duì)的)的平均數(shù)。該值應(yīng)不超過磁盤數(shù)的1.5~2 倍。要提高性能，可增加磁盤。注意：一個(gè)Raid Disk實(shí)際有多個(gè)磁盤。
Average disk read/write queue length： 指讀取(寫入)請求(列隊(duì))的平均數(shù)Disk reads/(writes)/s：理磁盤上每秒鐘磁盤讀、寫的次數(shù)。兩者相加，應(yīng)小于磁盤設(shè)備最大容量。
Average disk sec/read：以秒計(jì)算的在此盤上讀取數(shù)據(jù)的所需平均時(shí)間。Average disk sec/transfer：指以秒計(jì)算的在此盤上寫入數(shù)據(jù)的所需平均時(shí)間。
Bytes total/sec：為發(fā)送和接收字節(jié)的速率，包括幀字符在內(nèi)。判斷網(wǎng)絡(luò)連接速度是否是瓶頸，可以用該計(jì)數(shù)器的值和目前網(wǎng)絡(luò)的帶寬比較Page read/sec：每秒發(fā)出的物理數(shù)據(jù)庫頁讀取數(shù)。這一統(tǒng)計(jì)信息顯示的是在所有數(shù)據(jù)庫間的物理頁讀取總數(shù)。由于物理 I/O 的開銷大，可以通過使用更大的數(shù)據(jù)高速緩存、智能索引、更高效的查詢或者改變數(shù)據(jù)庫設(shè)計(jì)等方法，使開銷減到最小。
Page write/sec：(寫的頁/秒)每秒執(zhí)行的物理數(shù)據(jù)庫寫的頁數(shù)。
內(nèi)容導(dǎo)航
1. 判斷應(yīng)用程序的問題
如果系統(tǒng)由于應(yīng)用程序代碼效率低下或者系統(tǒng)結(jié)構(gòu)設(shè)計(jì)有缺陷而導(dǎo)致大量的上下文切換(context switches/sec顯示的上下文切換次數(shù)太高)那么就會(huì)占用大量的系統(tǒng)資源,如果系統(tǒng)的吞吐量降低并且CPU的使用率很高,并且此現(xiàn)象發(fā)生時(shí)切換水平在15000以上,那么意味著上下文切換次數(shù)過高.
從圖的整體看.context switches/sec變化不大,throughout曲線的斜率較高,并且此時(shí)的contextswitches/sec已經(jīng)超過了15000.程序還是需要進(jìn)一步優(yōu)化.
2. 判斷CPU瓶頸
如果processor queue length顯示的隊(duì)列長度保持不變(>=2)個(gè)并且處理器的利用率%Processortime超過90%,那么很可能存在處理器瓶頸.如果發(fā)現(xiàn)processor queue length顯示的隊(duì)列長度超過2,而處理器的利用率卻一直很低,或許更應(yīng)該去解決處理器阻塞問題,這里處理器一般不是瓶頸.
%processor time平均值大于95,processor queue length大于2.可以確定CPU瓶頸.此時(shí)的CPU已經(jīng)不能滿足程序需要.急需擴(kuò)展.
3. 判斷內(nèi)存泄露問題
內(nèi)存問題主要檢查應(yīng)用程序是否存在內(nèi)存泄漏,如果發(fā)生了內(nèi)存泄漏,process\private bytes計(jì)數(shù)器和process\working set 計(jì)數(shù)器的值往往會(huì)升高,同時(shí)avaiable bytes的值會(huì)降低.內(nèi)存泄漏應(yīng)該通過一個(gè)長時(shí)間的,用來研究分析所有內(nèi)存都耗盡時(shí),應(yīng)用程序反應(yīng)情況的測試來檢驗(yàn).
圖中可以看到該程序并不存在內(nèi)存泄露的問題.內(nèi)存泄露問題經(jīng)常出現(xiàn)在服務(wù)長時(shí)間運(yùn)轉(zhuǎn)的時(shí)候,由于部分程序?qū)?nèi)存沒有釋放,而將內(nèi)存慢慢耗盡.也是提醒大家對系統(tǒng)穩(wěn)定性測試的關(guān)注.
附件:
CPU信息：
Processor\ % Processor Time 獲得處理器使用情況。
也可以選擇監(jiān)視 Processor\ % User Time 和 % Privileged Time 以獲得詳細(xì)信息。
Server Work Queues\ Queue Length 計(jì)數(shù)器會(huì)顯示出處理器瓶頸。隊(duì)列長度持續(xù)大于 4 則表示可能出現(xiàn)處理器擁塞。
System\ Processor Queue Length 用于瓶頸檢測通過使用 Process\ % Processor Time 和 Process\ Working Set
Process\ % Processor Time過程的所有線程在每個(gè)處理器上的處理器時(shí)間總和。
硬盤信息：
Physical Disk\ % Disk Time
Physical Disk\ Avg.Disk Queue Length
例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果頁面讀取操作速率很低，同時(shí) % Disk Time 和 Avg.Disk Queue Length的值很高，則可能有磁盤瓶徑。但是，如果隊(duì)列長度增加的同時(shí)頁面讀取速率并未降低，則內(nèi)存不足。
Physical Disk\ % Disk Time
Physical Disk\ Avg.Disk Queue Length
例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果頁面讀取操作速率很低，同時(shí) % Disk Time 和 Avg.Disk Queue Length的值很高，則可能有磁盤瓶徑。但是，如果隊(duì)列長度增加的同時(shí)頁面讀取速率并未降低，則內(nèi)存不足。
請觀察 Processor\ Interrupts/sec 計(jì)數(shù)器的值，該計(jì)數(shù)器測量來自輸入/輸出 (I/O) 設(shè)備的服務(wù)請求的速度。如果此計(jì)數(shù)器的值明顯增加，而系統(tǒng)活動(dòng)沒有相應(yīng)增加，則表明存在硬件問題。
Physical Disk\ Disk Reads/sec and Disk Writes/sec
Physical Disk\ Current Disk Queue Length
Physical Disk\ % Disk Time
LogicalDisk\ % Free Space |
測試磁盤性能時(shí)，將性能數(shù)據(jù)記錄到另一個(gè)磁盤或計(jì)算機(jī)，以便這些數(shù)據(jù)不會(huì)干擾您正在測試的磁盤。
可能需要觀察的附加計(jì)數(shù)器包括 Physical Disk\ Avg.Disk sec/Transfer 、Avg.DiskBytes/Transfer，和Disk Bytes/sec。
Avg.Disk sec/Transfer 計(jì)數(shù)器反映磁盤完成請求所用的時(shí)間。較高的值表明磁盤控制器由于失敗而不斷重試該磁盤。這些故障會(huì)增加平均磁盤傳送時(shí)間。對于大多數(shù)磁盤，較高的磁盤平均傳送時(shí)間是大于 0.3 秒。
也可以查看 Avg.Disk Bytes/Transfer 的值。值大于 20 KB 表示該磁盤驅(qū)動(dòng)器通常運(yùn)行良好;如果應(yīng)用程序正在訪問磁盤，則會(huì)產(chǎn)生較低的值。例如，隨機(jī)訪問磁盤的應(yīng)用程序會(huì)增加平均 Disk sec/Transfer 時(shí)間，因?yàn)殡S機(jī)傳送需要增加搜索時(shí)間。
Disk Bytes/sec 提供磁盤系統(tǒng)的吞吐率。
決定工作負(fù)載的平衡要平衡網(wǎng)絡(luò)服務(wù)器上的負(fù)載，需要了解服務(wù)器磁盤驅(qū)動(dòng)器的繁忙程度。使用 Physical Disk\ %Disk Time 計(jì)數(shù)器，該計(jì)數(shù)器顯示驅(qū)動(dòng)器活動(dòng)時(shí)間的百分比。如果 % Disk Time 較高(超過90%)，請檢查 Physical Disk\ Current Disk Queue Length 計(jì)數(shù)器以查看正在等待磁盤訪問的系統(tǒng)請求數(shù)量。等待 I/O 請求的數(shù)量應(yīng)當(dāng)保持在不大于組成物理磁盤的主軸數(shù)的 1.5 到2倍。
盡管廉價(jià)磁盤冗余陣列 (RAID) 設(shè)備通常有多個(gè)主軸，大多數(shù)磁盤有一個(gè)主軸。硬件 RAID設(shè)備在“系統(tǒng)監(jiān)視器”中顯示為一個(gè)物理磁盤;通過軟件創(chuàng)建的 RAID 設(shè)備顯示為多個(gè)驅(qū)動(dòng)器(實(shí)例)。可以監(jiān)視每個(gè)物理驅(qū)動(dòng)器(而不是 RAID)的 Physical Disk 計(jì)數(shù)器，也可以使用 _Total 實(shí)例來監(jiān)視所有計(jì)算機(jī)驅(qū)動(dòng)器的數(shù)據(jù)。
使用 Current Disk Queue Length 和 % Disk Time 計(jì)數(shù)器來檢測磁盤子系統(tǒng)的瓶頸。如果Current Disk Queue Length 和 % Disk Time 的值始終較高，可以考慮升級磁盤驅(qū)動(dòng)器或?qū)⒛承┪募苿?dòng)到其他磁盤或服務(wù)器。