loadrunner-analysis實(shí)例結(jié)果圖表分析

《loadrunner-analysis實(shí)例結(jié)果圖表分析》由會員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫。

1、這個(gè)例子主要講述的是多個(gè)用戶同時(shí)接管任務(wù)，測試系統(tǒng)的響應(yīng)能力，確定系統(tǒng)瓶頸所在?？蛻粢箜憫?yīng)時(shí)間是1個(gè)人接管的時(shí)間在5S內(nèi)。打開Analysis首先可以看到的是SummaryReport。這里顯示了測試的分析摘要，但是我們并不需要每個(gè)都仔細(xì)去看。下面介紹一下部分的含義：Duration(持續(xù)時(shí)間)：了解該測試過程持續(xù)時(shí)間。測試人員本身要對這個(gè)時(shí)期內(nèi)系統(tǒng)一共做了多少的事有大致的熟悉了解.以確定下次增加更多的任務(wù)條件下測試的持續(xù)時(shí)間。StatisticsSummary(統(tǒng)計(jì)摘要)：只是大概了解一下測試數(shù)據(jù)，對我們具體分析沒有太大的作用.TransactionS

2、ummary(事務(wù)摘要)：了解平均響應(yīng)時(shí)間Average單位為秒。其余的看不看都可以，都不是很重要。1、分析集合點(diǎn)在錄制腳本中通常我們會使用到集合點(diǎn)，那么既然我們用到了集合點(diǎn)，我們就需要知道Vuser是在什么時(shí)候集合在這個(gè)點(diǎn)上，又是怎樣的一個(gè)被釋放的過程。這個(gè)時(shí)候就需要觀察Rendezvous圖。(添加新圖-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、集合點(diǎn)與平均事務(wù)響應(yīng)時(shí)

3、間的比較圖。圖2注：打開圖的具體步驟:點(diǎn)擊圖上，右鍵選擇mergegraphs，然后在selectgraphtomergewith中選擇即將用來進(jìn)行比較的graph。圖2中較深顏色的是平均響應(yīng)時(shí)間，淺色的為集合點(diǎn)，當(dāng)Vuser在集合點(diǎn)持續(xù)了1分后平均響應(yīng)時(shí)間呈現(xiàn)最大值，可見用戶的并發(fā)對系統(tǒng)的性能是一個(gè)很大的考驗(yàn)。3、接下來看一下與事務(wù)有關(guān)的參數(shù)分析。AverageTransactionResponseTime和RunningVuser兩個(gè)數(shù)據(jù)圖圖4從圖中可以看到Vuser_init_Transaction(系統(tǒng)登錄)對系統(tǒng)無任何的影響，Vuser達(dá)到15個(gè)

4、的時(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è)，看來是很難滿足用戶的需求了。4、TransactionResponseTime(Percentile)查看百分比圖中畫圈的地方表示10%的事務(wù)響應(yīng)時(shí)間是在80S左右。80S對于用戶來說不是一個(gè)很小的數(shù)字，而且只有10%的事務(wù)，

5、汗！你覺得這個(gè)系統(tǒng)性能會好么！實(shí)際工作中遇到的事情不是每一件事都能夠在很短的時(shí)間內(nèi)完成的，對于那些需要時(shí)間的事情我們就要分配適當(dāng)?shù)臅r(shí)間處理，時(shí)間分配的不均勻就會出現(xiàn)有些事情消耗的時(shí)間長一些，有些事情消耗的短一些，但我們自己清楚LR同樣也為我們提供了這樣的功能，使我們可以了解大部分的事務(wù)響應(yīng)時(shí)間是多少，以確定這個(gè)系統(tǒng)我們還要付出多少的代價(jià)來提高它。5、TransactionResponseTime(Distribution)-事務(wù)響應(yīng)時(shí)間(分布)顯示在方案中執(zhí)行事務(wù)所用時(shí)間的分布。如果定義了可以接受的最小和最大事務(wù)性能時(shí)間，可以通過此圖確定服務(wù)器性能是否在可

6、接受范圍內(nèi)。很明顯大多數(shù)事務(wù)的響應(yīng)時(shí)間在60-140S。一般多數(shù)客戶所能接受的最大響應(yīng)時(shí)間也要在20S左右。140S的時(shí)間很少有人會去花這么多的時(shí)間去等待頁面的出現(xiàn)吧！通過觀察以上的數(shù)據(jù)表，我們不難看到此系統(tǒng)在這種環(huán)境下并不理想。世間事有果就有因，那么是什么原因?qū)е碌孟到y(tǒng)性能這樣差呢？讓我們一步一步的分析。系統(tǒng)性能不好的原因多方面，我們先從應(yīng)用程序看，有的時(shí)候我不得不承認(rèn)LR的功能真的很強(qiáng)大，這也是我喜歡它的原因。6、頁面細(xì)分圖。（如果analysis中找不到該圖，運(yùn)行之前在run-time-setting中preference勾選pagesperseco

7、nd(HTMLModeonlyanalysis中就會有)一個(gè)應(yīng)用程序是由很多個(gè)組件組成的，整個(gè)系統(tǒng)性能不好那我們就把它徹底的剖析一下。圖片中顯示了整個(gè)測試過程中涉及到的所有web頁。webpagebreakdown中顯示的是每個(gè)頁面的下載時(shí)間。點(diǎn)選左下角webpagebreakdown展開，可以看到每個(gè)頁中包括的css樣式表，js腳本，jsp頁面等所有的屬性。在selectpagetobreakdown中選擇頁面。見圖。在SelectPageToBreakdown中選擇http://192.168.0.135:8888/usertasks后，在下方看到屬于

8、它的兩個(gè)組件，第一行中Connection和FirstBuffer