性能測試進(jìn)階指南：Loadrunner實(shí)戰(zhàn)91-第5章 數(shù)據(jù)收集分析

1、.：.；目錄 TOC o 1-3 h z u HYPERLINK l _Toc298338050 第5章 數(shù)據(jù)搜集分析Analysis PAGEREF _Toc298338050 h 2 HYPERLINK l _Toc298338051 5.1 新建Analysis分析 PAGEREF _Toc298338051 h 2 HYPERLINK l _Toc298338052 5.2 Analysis Summary PAGEREF _Toc298338052 h 2 HYPERLINK l _Toc298338053 5.2.1 Analysis Summary(場景的摘要) PAGEREF

2、_Toc298338053 h 3 HYPERLINK l _Toc298338054 5.2.2 Statistics Summary(場景形狀的統(tǒng)計闡明) PAGEREF _Toc298338054 h 3 HYPERLINK l _Toc298338055 5.2.3 5Worst Transaction(SLA失敗事務(wù)) PAGEREF _Toc298338055 h 4 HYPERLINK l _Toc298338056 5.2.4 Scenario Behavior Over Time(場景行為綜述) PAGEREF _Toc298338056 h 5 HYPERLINK l _T

3、oc298338057 5.2.5 Transaction Summary(事務(wù)摘要) PAGEREF _Toc298338057 h 5 HYPERLINK l _Toc298338058 5.2.6 Service Level Agreement Legend(SLA圖標(biāo)闡明) PAGEREF _Toc298338058 h 7 HYPERLINK l _Toc298338059 5.2.7 Responses Summary(HTTP呼應(yīng)摘要) PAGEREF _Toc298338059 h 7 HYPERLINK l _Toc298338060 5.3 Graphs(數(shù)據(jù)圖) PAGE

4、REF _Toc298338060 h 8 HYPERLINK l _Toc298338061 5.3 .1 Vusers(虛擬用戶形狀) PAGEREF _Toc298338061 h 10 HYPERLINK l _Toc298338062 5.3.2 Errors(錯誤統(tǒng)計) PAGEREF _Toc298338062 h 11 HYPERLINK l _Toc298338063 5.3.3 Transactions(事務(wù)) PAGEREF _Toc298338063 h 11 HYPERLINK l _Toc298338064 5.3.4 WebResources(網(wǎng)頁資源信息) PA

5、GEREF _Toc298338064 h 15 HYPERLINK l _Toc298338065 5.3.5 Web Page Diagnostics(網(wǎng)頁分析) PAGEREF _Toc298338065 h 17 HYPERLINK l _Toc298338066 5.3.6 Network Monitor(網(wǎng)絡(luò)監(jiān)控) PAGEREF _Toc298338066 h 22 HYPERLINK l _Toc298338067 5.3.7 Resources(資源監(jiān)控) PAGEREF _Toc298338067 h 23 HYPERLINK l _Toc298338068 5.4 圖設(shè)置

6、與操作 PAGEREF _Toc298338068 h 34 HYPERLINK l _Toc298338069 5.4.1 Merge Graphs (合并圖) PAGEREF _Toc298338069 h 34 HYPERLINK l _Toc298338070 5.4.2 Auto Correlate(自動定位瓶頸) PAGEREF _Toc298338070 h 37 HYPERLINK l _Toc298338071 5.5 Transaction Report(事務(wù)報告) PAGEREF _Toc298338071 h 40 HYPERLINK l _Toc298338072 5

7、.6 SLA Report(系統(tǒng)閾值監(jiān)控報告) PAGEREF _Toc298338072 h 42 HYPERLINK l _Toc298338073 5.7 External Monitor(外部監(jiān)控數(shù)據(jù)導(dǎo)入) PAGEREF _Toc298338073 h 43 HYPERLINK l _Toc298338074 5.8 Cross with result(跨腳本橫向比較) PAGEREF _Toc298338074 h 45 HYPERLINK l _Toc298338075 5.9 生成測試報告 PAGEREF _Toc298338075 h 46 HYPERLINK l _Toc2

8、98338076 5.9.1 創(chuàng)建HTML報告 PAGEREF _Toc298338076 h 46 HYPERLINK l _Toc298338077 5.9.2 創(chuàng)建Word報告 PAGEREF _Toc298338077 h 47 HYPERLINK l _Toc298338078 5.9.3 創(chuàng)建水晶報表 PAGEREF _Toc298338078 h 47 HYPERLINK l _Toc298338079 小結(jié) PAGEREF _Toc298338079 h 49第5章 數(shù)據(jù)搜集分析Analysis經(jīng)過場景完成負(fù)載后，我們完成了性能測試的執(zhí)行過程，接著就是經(jīng)過負(fù)載的結(jié)果來發(fā)現(xiàn)和定位

9、性能瓶頸。在這里Analysis就好比一個數(shù)據(jù)分析中心或數(shù)據(jù)倉庫，它將場景運(yùn)轉(zhuǎn)中所能得到的數(shù)據(jù)都整合在一同，可以對測試結(jié)果數(shù)據(jù)進(jìn)展整理，并提供了一些方法可以進(jìn)一步對結(jié)果數(shù)據(jù)進(jìn)展分析，從而找出系統(tǒng)的性能目的和能夠的瓶頸，最終生成報告?？梢园袮nalysis看作一個股票分析軟件，將股票的數(shù)據(jù)搜集分析后生成K線圖，而詳細(xì)闡明了什么，還要依賴于分析者本身。運(yùn)用Analysis進(jìn)展性能測試結(jié)果的分析流程如圖5.1所示。圖5.1 Analysis結(jié)果分析流程5.1 新建Analysis分析導(dǎo)入場景數(shù)據(jù)生成Analysis報告的方式有以下三種：當(dāng)場景運(yùn)轉(zhuǎn)終了后在場景直接運(yùn)轉(zhuǎn)Results菜單下的Analyz

10、e Results命令進(jìn)入Analysis。2在Analysis中翻開新建菜單，然后進(jìn)入場景運(yùn)轉(zhuǎn)終了后的場景結(jié)果res目錄，接著Analysis會對整個場景數(shù)據(jù)進(jìn)展整理，給出簡明報告及相關(guān)圖表。3在場景結(jié)果目錄中直接雙擊Mercury LoadRunner Result(.lrr)文件。5.2 Analysis Summary當(dāng)Analysis導(dǎo)入場景數(shù)據(jù)后，首先映入眼簾的是統(tǒng)計表格Analysis Summary場景摘要，提供了對整個場景數(shù)據(jù)的簡單報告。下面引見一下該報告的各個組成部分。5.2.1 Analysis Summary(場景的摘要)這里給出了場景的摘要(Analysis Summ

11、ary)，包括以下內(nèi)容：Period：場景運(yùn)轉(zhuǎn)的起止時間Scenario Name：場景稱號Resultsin Session：場景運(yùn)轉(zhuǎn)的結(jié)果目錄Duration：場景運(yùn)轉(zhuǎn)的時間經(jīng)過場景摘要可以了解場景執(zhí)行的根底信息。5.2.2 Statistics Summary(場景形狀的統(tǒng)計闡明)場景形狀的統(tǒng)計闡明(Statistics Summary)包含以下內(nèi)容：Maximum Running Vusers：場景最大用戶數(shù)Total Throughput(bytes)：總帶寬流量Average Throughput(bytes/second)：平均每秒帶寬流量Total Hits：總點(diǎn)擊數(shù)Avera

12、ge Hits per Second：平均每秒點(diǎn)擊數(shù)單擊View Responses Summary選項可以切換到報告的最下端查看HTTP懇求的統(tǒng)計。在每項數(shù)據(jù)標(biāo)題和數(shù)據(jù)中，還會看到一個小的球形圖標(biāo)囊，單擊后會進(jìn)入SLA分析報告。5.2.3 5Worst Transaction(SLA失敗事務(wù))這里列出了對5大失敗事務(wù)的統(tǒng)計，只需當(dāng)在Controller或Analysis中定義了SLA status determined at time intervals over a timeline監(jiān)控時才會出現(xiàn)該報告。Transaction Name(事務(wù)名)。Failure Ratio(exceede

13、d time/transaction duration)失敗率(超標(biāo)次數(shù)/事務(wù)繼續(xù)時間)。該值反映了在一切事務(wù)中有百分之多少的事務(wù)是無法到達(dá)SLA基準(zhǔn)值。Failure Value(response time/SLA)失敗率(呼應(yīng)時間/SLA)。該值反映了在整個場景運(yùn)轉(zhuǎn)下，SLA的定義規(guī)范值與實(shí)踐事務(wù)值超標(biāo)的平均百分比，也就是說平均算下來真實(shí)的呼應(yīng)時間和定義的閾值誤差百分比。經(jīng)過這行報告，我們可以明晰地了解該事務(wù)有多少是無法到達(dá)SLA規(guī)范的，以及無法到達(dá)規(guī)范的事務(wù)與SLA的誤差范圍是多少。單擊事務(wù)名前的加號還能列出該事務(wù)在SLA定義的繼續(xù)時間下平均誤差比例和最大誤差比例。Analysis會根據(jù)

14、SLA中的定義分析事務(wù)的經(jīng)過率，在這個場景結(jié)果中，一切的事務(wù)呼應(yīng)時間都在SLA監(jiān)控值以外，所以結(jié)果為Infinity全部超標(biāo)。分析的失敗事務(wù)數(shù)可以在Tools菜單下Options的General標(biāo)簽中進(jìn)展設(shè)置，默以為5個事務(wù)，如圖52所示。圖52 SummaryReport設(shè)置5.2.4 Scenario Behavior Over Time(場景行為綜述)這里列出了在場景中定義的事務(wù)在各個時間點(diǎn)上的SLA情況，背景中的x表示在這個時間點(diǎn)上事務(wù)沒有到達(dá)SLA的目的。而上面的Application Under Test Errors顯示了在每個時間段上的錯誤數(shù)目。5.2.5 Transactio

15、n Summary(事務(wù)摘要) 這里首先給出的是場景中一切事務(wù)的情況闡明：TotalPassed(事務(wù)的總經(jīng)過數(shù))TotalFailed(事務(wù)的總失敗數(shù))TotalStopped(事務(wù)的總停頓數(shù))Average Response Time是一個鏈接，可以翻開事務(wù)平均呼應(yīng)時間圖表。下面給出每個詳細(xì)事務(wù)的情況列表，可以看到以下數(shù)據(jù)項：Transaction Name(事務(wù)名)SLA Status(SLA形狀)：在SLA的目的測試中最終結(jié)果是經(jīng)過還是失敗Minimum(事務(wù)最小時間)Average(事務(wù)平均時間)Maximum(事務(wù)最大時間)Std.Deviation(規(guī)范方差)規(guī)范方差，這個數(shù)據(jù)是

16、描畫采樣數(shù)據(jù)離散形狀很重要的目的，它又分為以下兩種：1給定樣本規(guī)范方差，它是估算給定樣本而不是整個樣本的規(guī)范方差(也就是樣本中的一部分)，計算公式如下：其中X代表平均值，n代表取樣個數(shù)。n-1是統(tǒng)計學(xué)上的常用做法，主要思索到采樣量越大，越能反映真實(shí)的情況。2總體樣本規(guī)范方差，它是估算整個采樣樣本的規(guī)范方差(留意是整個采樣數(shù)據(jù)而不是部分)，計算公式如下：當(dāng)采樣數(shù)據(jù)足夠大的時候，上述兩種計算方式得出的偏向相差很小。規(guī)范方差相對于平均值越大，闡明數(shù)據(jù)越離散，那么分布形狀相對于平均值動搖很大；規(guī)范方差相對于平均值越小，闡明數(shù)據(jù)分布越集中，曲線也越平穩(wěn)。在采樣值服從正態(tài)分布的條件下經(jīng)過上面的目的結(jié)合平均

17、值、最大值、最小值，可以比較清楚地知道采樣數(shù)據(jù)的分布形狀及其能否有較大的動搖。90Percent(用戶感受百分比)這個值闡明的采樣數(shù)據(jù)中有90的數(shù)據(jù)比它小，有10的數(shù)據(jù)比它大，舉例如下：假設(shè)有一組數(shù)據(jù)(1、3、4、6、5、7、8、2、9、10)，從小到大排序之后為(1、2、3、4、5、6、7、8、9、10)，在這10個數(shù)字中第九大的數(shù)字是9，所以90 Percent的結(jié)果就是9。它的主要作用就是來了解在某個呼應(yīng)時間內(nèi)有百分之多少的用戶。當(dāng)然這個90是可調(diào)整的，在Analysis中經(jīng)過View菜單中SummaryFilter下的Transaction Percentile選項來調(diào)整。Pass(事

18、務(wù)經(jīng)過數(shù))Fail(事務(wù)失敗數(shù))Stop(事務(wù)停頓數(shù))5.2.6 Service Level Agreement Legend(SLA圖標(biāo)闡明) 圖標(biāo)為灰色帶減號的為No Data，闡明在SLA中未對這個數(shù)據(jù)項進(jìn)展監(jiān)控，沒有數(shù)據(jù)；圖標(biāo)為紅色帶叉的為Fail，闡明在SLA中定義了該項的數(shù)據(jù)監(jiān)控，但該數(shù)據(jù)未能到達(dá)期望的閾值；圖片為綠色帶鉤的為Pass，闡明在SLA中定義了該項的數(shù)據(jù)監(jiān)控，該數(shù)據(jù)到達(dá)了的期望閾值。5.2.7 Responses Summary(HTTP呼應(yīng)摘要)這里給出了效力器前往的形狀。效力器前往HTTP懇求形狀( Responses，詳細(xì)的效力器前往形狀碼見附錄A)HTTP懇求前

19、往次數(shù)(Total)每秒懇求數(shù)(Per second)經(jīng)過Analysis Summary可以對整個性能測試的結(jié)果有一個直觀的引見，特別是經(jīng)過SLA的數(shù)據(jù)可以直觀地了解在整個負(fù)載中系統(tǒng)的性能目的能否滿足閾值，除此以外設(shè)置的事務(wù)呼應(yīng)時間數(shù)據(jù)也會顯示。Analysis保管后會生成Mercury LoadRunner Analysis Session(lra)文件。經(jīng)過File菜單下的Session Information功能可以了解該Session文件的屬性，而File菜單下的View Scenario RunTime Settings功能可以查看該報告場景的運(yùn)轉(zhuǎn)設(shè)置。當(dāng)粗略了解了整個場景的情況后

20、，根據(jù)場景執(zhí)行前的目的，可以對整個系統(tǒng)的性能有一定的了解，接著需求對關(guān)懷的數(shù)據(jù)進(jìn)展進(jìn)一步的了解和分析。5.3 Graphs(數(shù)據(jù)圖)在場景運(yùn)轉(zhuǎn)時可以看到一些圖，這些圖將場景中的數(shù)據(jù)轉(zhuǎn)化為折線圖，方便我們了解當(dāng)前該數(shù)據(jù)的形狀。在默許情況下，Analysis會自動翻開如圖53所示的幾張圖。這是系統(tǒng)最根本的幾個圖，這些圖反映了在不同時間段相關(guān)計數(shù)器的數(shù)據(jù)變化情況，可以經(jīng)過在Graphs上右鍵菜單中的Add New Graphs命令完成添加圖的操作，添加后彈出Graphs管理器，如圖5.4所示。在Open a NewGraph窗口中，可以得到一切能添加的計數(shù)器圖形，勾選左下角的Display only

21、 graphs containing data選項可以隱藏沒有數(shù)據(jù)的計數(shù)器，有數(shù)據(jù)的計數(shù)器那么會以藍(lán)色顯示在左側(cè)區(qū)域。而選中詳細(xì)的圖，在右側(cè)的Graph Description中會有更加詳細(xì)的引見。在Graph Properties中還可以對生成的圖表進(jìn)展一定的屬性設(shè)置，例如生成的圖是運(yùn)用整個場景的時間還是其中的某一部分時間。 圖53默許情況下系統(tǒng)翻開的Graphs圖54數(shù)據(jù)圖管理器對于恣意一張圖，都可以在右側(cè)看到有2個功能：User Notes和Raw Data。UserNotes提供對某張圖進(jìn)展文字描畫的功能；Raw Data是將生成該圖的數(shù)據(jù)列出。在RawData中單擊Click to

22、retrieve raw data，會彈出Raw Data窗口，設(shè)置場景繼續(xù)的時間，確認(rèn)后可以得到該時間段內(nèi)組成該圖的一切數(shù)據(jù)，如圖55所示。圖5.5 RawData數(shù)據(jù)表這里可以將數(shù)據(jù)另存為Excel文件，再經(jīng)過第三方工具進(jìn)展分析。例如將導(dǎo)出的場景數(shù)據(jù)運(yùn)用SPSS工具進(jìn)展進(jìn)一步的數(shù)學(xué)分析。在圖的下方，Legend窗口會顯示圖中對象闡明信息以及相關(guān)數(shù)據(jù)，如圖56所示。經(jīng)過對顯示對象的一些設(shè)置，可以得到更好的顯示效果。在Legend窗口中單擊鼠標(biāo)右鍵，彈出菜單如圖57所示。圖56Legend圖中對象數(shù)聽闡明圖57Legend設(shè)置選項菜單可以經(jīng)過Show/Hide/Show only select

23、ed/Show all命令設(shè)置所需求選的工程，也可以經(jīng)過Configure measurements/Show measurement description命令設(shè)置線條的顏色及顯示方式。Animate selected line選項可以在切換線條時獲得更加明顯的動畫效果，Auto Correlate提供了對所選對象的自動關(guān)聯(lián)操作(參考542節(jié))，而在Configure columns中可以設(shè)置在Legend中顯示哪些屬性名。每張圖都代表了場景運(yùn)轉(zhuǎn)中監(jiān)控到的數(shù)據(jù)變化趨勢，所以看懂每一張圖的含義是性能分析的第一步，接著我們來引見一些常見圖的含義。5.3 .1 Vusers(虛擬用戶形狀)Vuse

24、rs用戶形狀計數(shù)器組提供了產(chǎn)生負(fù)載的虛擬用戶運(yùn)轉(zhuǎn)形狀的相關(guān)信息，可以協(xié)助 我們了解負(fù)載生成的過程。Running Vusers(負(fù)載過程中的虛擬用戶運(yùn)轉(zhuǎn)情況)該圖可以反映系統(tǒng)構(gòu)成負(fù)載的過程，隨著時間的推移，虛擬用戶數(shù)是如何變化的。在圖58中可以看到用戶在9分鐘左右到達(dá)了負(fù)載峰值50個虛擬用戶，負(fù)載的生成是大約每分鐘添加5個用戶，峰值負(fù)載繼續(xù)1分30秒。圖5.8 Running VusersRendezvous(負(fù)載過程中集合點(diǎn)下的虛擬用戶數(shù))當(dāng)場景中設(shè)置了集合點(diǎn)后會出現(xiàn)這張圖，該圖反映了隨著時間的推移各個時間點(diǎn)上并發(fā)用戶的數(shù)目，方便我們了解并發(fā)用戶數(shù)的變化情況。在圖59中可以看到剛開場的7分鐘

25、內(nèi)，負(fù)載的并發(fā)用戶都是1個，而后面變化為2個用戶并發(fā)。圖5.9 Rendezvous5.3.2 Errors(錯誤統(tǒng)計)當(dāng)場景在運(yùn)轉(zhuǎn)中出現(xiàn)錯誤時，錯誤信息將會被保管在該計數(shù)器組中，經(jīng)過Error信息可以了解錯誤產(chǎn)生的時間和錯誤的類型，協(xié)助 我們定位產(chǎn)生錯誤的緣由。Errors per Second(每秒錯誤數(shù))經(jīng)過每秒錯誤數(shù)可以了解在每個時間點(diǎn)上錯誤產(chǎn)生的數(shù)目，該數(shù)據(jù)越小越好。經(jīng)過這個圖可以了解錯誤隨負(fù)載的變化情況，定位何時系統(tǒng)在負(fù)載下開場不穩(wěn)定甚至出錯，配合系統(tǒng)日志可以定位產(chǎn)生錯誤的緣由。在圖510中可以看到場景在37秒的時候出現(xiàn)了一次錯誤。圖5.10 Errors per Second5.

26、3.3 Transactions(事務(wù))這里給出了一切和事務(wù)相關(guān)的數(shù)據(jù)統(tǒng)計，方便了解被測系統(tǒng)業(yè)務(wù)處置的呼應(yīng)時間和吞吐量，在39節(jié)中引見了系統(tǒng)事務(wù)默許有3種形狀PASS、FAIL、STOP，假設(shè)是手工事務(wù)那么形狀會有PASS和FAIL兩種。Average Transaction Response Time(平均事務(wù)呼應(yīng)時間)這是我們比較關(guān)懷的數(shù)據(jù)之一，反映隨著時間的變化事務(wù)呼應(yīng)時間的變化情況，時間越小闡明處置的速度越快。假設(shè)和前面的用戶負(fù)載生成圖合并在一同看，就可以發(fā)現(xiàn)用戶負(fù)載添加對系統(tǒng)事務(wù)呼應(yīng)時間的影響規(guī)律。在圖511中可以看到呼應(yīng)時間是如何增長的，隨著時間的推移呼應(yīng)時間逐漸變長，并且在不到8

27、分鐘的時候忽然出現(xiàn)呼應(yīng)時間大幅下降的情況。圖5。11 Average Transaction Response Time另外事務(wù)的呼應(yīng)時間也不應(yīng)該超越用戶的最大接受范圍，否那么會出現(xiàn)系統(tǒng)呼應(yīng)過慢的問題。Transactions per Second(每秒事務(wù)數(shù))另一個關(guān)鍵數(shù)據(jù)是TPS吞吐量，該數(shù)據(jù)反映了系統(tǒng)在同一時間內(nèi)能處置業(yè)務(wù)的最大才干，這個數(shù)據(jù)越高，闡明系統(tǒng)處置才干越強(qiáng)。在圖512中上面的線是經(jīng)過的事務(wù)，下面的線是失敗的事務(wù)，這里可以看到系統(tǒng)的TPS隨著時間的變化逐漸變大，而在不到10分鐘的時候系統(tǒng)每秒可以處置1.9個事務(wù)。這里的最高值并不一定代表系統(tǒng)的最大處置才干，TPS會遭到負(fù)載的影響

28、，也會隨著負(fù)載的添加而逐漸添加，當(dāng)系統(tǒng)進(jìn)入忙碌期后，TPS會有所下降。而在4分鐘以后開場出現(xiàn)少量的失敗事務(wù)。圖5.12 Transactions per SecondTransactionSummary(事務(wù)概要闡明)該闡明給出事務(wù)的Pass個數(shù)和Fail個數(shù)，了解負(fù)載的事務(wù)完成情況。經(jīng)過的事務(wù)數(shù)越多，闡明系統(tǒng)的處置才干越強(qiáng)；失敗的事務(wù)越少，闡明系統(tǒng)越可靠。在圖513中可以看出，對于reg注冊操作一共有613次操作勝利，有6次失敗?？梢运妓鹘Y(jié)合前面的每秒錯誤數(shù)進(jìn)一步分析為什么會出現(xiàn)6個注冊錯誤，以及錯誤發(fā)生的時間和該時間產(chǎn)生錯誤的緣由。圖5.13 Transaction SummaryTran

29、saction PerformanceS ummary(事務(wù)性能概要)這里會給出事務(wù)的平均時間、最大時間、最小時間柱狀圖，方便分析事務(wù)呼應(yīng)時間的情況。在圖5.14中可以看到reg這個事務(wù)最大時間為3.897s，最小時間為2.555s，平均時間為2.924s。柱狀圖的落差越小闡明呼應(yīng)時間的動搖較小，假設(shè)落差很大，那么闡明系統(tǒng)不夠穩(wěn)定。圖5.14 Transaction Performance SummaryTransaction Response Time Under Load(在用戶負(fù)載下事務(wù)呼應(yīng)時間)這里給出了在負(fù)載用戶增長的過程中呼應(yīng)時間的變化情況，其實(shí)這張圖也是將Vusers和Avera

30、ge Transaction Response Time圖做了一個Correlate Merge得到的，該圖的線條越平穩(wěn)，闡明系統(tǒng)越穩(wěn)定。在圖5.15中可以看出在負(fù)載逐漸添加到5個用戶時，事務(wù)的呼應(yīng)時間根本沒有變化。而用戶添加到15個開場，隨著用戶負(fù)載的添加呼應(yīng)時間也有較大的動搖。 圖5.15 Transaction Response Time Under LoadTransaction Response Time(Percentile)(事務(wù)呼應(yīng)時間的百分比)這里給出的是不同百分比下的事務(wù)呼應(yīng)時間范圍，經(jīng)過這個圖可以了解有多少比例的事務(wù)發(fā)生在某個時間內(nèi)，也可以發(fā)現(xiàn)呼應(yīng)時間的分布規(guī)律，數(shù)據(jù)越平

31、穩(wěn)闡明呼應(yīng)時間變化越小。在圖5.16中可以看到60的事務(wù)是在3秒內(nèi)。圖5.16 Transaction Response Time(Percentile)Transaction Response Time(Distribution)(每個時間段上的事務(wù)數(shù))該圖給出的是在每個時間段上的事務(wù)個數(shù)，呼應(yīng)時間較小的分類下的事務(wù)數(shù)越多越好。從圖5.17中可以看到在一切的事務(wù)中，有391個事務(wù)的呼應(yīng)時間最接近2秒，而有222個事務(wù)的呼應(yīng)時間最接近3秒。圖5.17 Transaction Response Time(Distribution)5.3.4 WebResources(網(wǎng)頁資源信息)這里給出的是對

32、于Web操作的一些根本信息，這些信息在效力器端也能獲得。當(dāng)Controller的RunTime Setting中Preferences下的Generated Web performance graphs選項處于開啟形狀時，該圖表才會出現(xiàn)。Hits per Second(每秒點(diǎn)擊數(shù))每秒點(diǎn)擊數(shù)提供了當(dāng)前負(fù)載中對系統(tǒng)所產(chǎn)生的點(diǎn)擊量記錄。每一次點(diǎn)擊相當(dāng)于對效力器發(fā)出了一次懇求，普通點(diǎn)擊數(shù)會隨著負(fù)載的添加而添加，該數(shù)據(jù)越大越好。在圖5.18中可以看出隨著時間的添加，每秒點(diǎn)擊數(shù)在上升，最高到達(dá)78次s。圖5.18 Hits per SecondThroughput(帶寬運(yùn)用)這里給出了在當(dāng)前系統(tǒng)負(fù)載下所

33、運(yùn)用的帶寬，該數(shù)據(jù)越小闡明系統(tǒng)的帶寬依賴越小，經(jīng)過這個數(shù)據(jù)能確定能否出現(xiàn)了網(wǎng)絡(luò)帶寬的瓶頸(留意這里運(yùn)用的單位是字節(jié))。在圖5.19中可以得到最高的帶寬峰值是355000B，遠(yuǎn)遠(yuǎn)低于100Mb的局域網(wǎng)帶寬上限，所以系統(tǒng)不存在帶寬瓶頸。圖5.19 Throughput Responses per Second(每秒HTTP呼應(yīng)數(shù))這里給出了每秒鐘效力器前往各種形狀的數(shù)目，該數(shù)值普通和每秒點(diǎn)擊量一樣。點(diǎn)擊量是指客戶端發(fā)出的懇求數(shù)，而HTTP呼應(yīng)數(shù)是指效力器前往的呼應(yīng)數(shù)。假設(shè)效力器前往的呼應(yīng)數(shù)小于客戶端發(fā)出的點(diǎn)擊數(shù)，那么闡明效力器無法應(yīng)對超出負(fù)載的銜接懇求。在圖5.20中可以看到最頂峰時效力器每秒能前

34、往接近75個HTTP 200 OK的形狀。圖5.20 responses per Second這個數(shù)據(jù)和前面的每秒點(diǎn)擊數(shù)吻合，闡明效力器可以對每一個客戶端懇求進(jìn)展應(yīng)對。Connections Per Second(每秒銜接數(shù))這里會給出兩種不同形狀的銜接數(shù)，即中斷的銜接和新建的銜接，方便用戶了解當(dāng)前每秒對效力器產(chǎn)生銜接的數(shù)量。在圖5.21中可以看到隨著時間的推移，系統(tǒng)的銜接數(shù)逐漸上升，最高到達(dá)每秒4個銜接。圖5.21 Connections Per Second同時的銜接數(shù)越多，闡明效力器的銜接池越大，當(dāng)銜接數(shù)隨著負(fù)載上升而停頓上升時，闡明系統(tǒng)的銜接池已滿，無法銜接更多的用戶，通常這個時候效力

35、器會前往504錯誤?？梢越?jīng)過修正效力器的最大銜接數(shù)來處理該問題。5.3.5 Web Page Diagnostics(網(wǎng)頁分析)當(dāng)在場景中翻開Diagnostics菜單下的Web Page Diagnostics功能，就能得到網(wǎng)頁分析組圖。經(jīng)過這個圖，可以對事務(wù)的組成進(jìn)展抽絲剝繭的分析，得到組成這個頁面的每一個懇求時間分析，進(jìn)一步了解呼應(yīng)時間中有關(guān)網(wǎng)絡(luò)和效力器處置時間的分配關(guān)系。經(jīng)過這個功能，可以實(shí)現(xiàn)對網(wǎng)站的前端性能分析，明確系統(tǒng)呼應(yīng)時間較長是由效力器端(后端)處置才干缺乏還是客戶端銜接到效力器的網(wǎng)絡(luò)(前端)耗費(fèi)導(dǎo)致的。更多內(nèi)容參考6.1.5節(jié)中的前端性能分析。Web Page Diagnos

36、tics(網(wǎng)頁分析)添加該圖先會得到整個場景運(yùn)轉(zhuǎn)后虛擬用戶訪問的Page列表，也就是一切頁面下載時間列表。這里對Discuz.Net論壇的注冊用戶事務(wù)進(jìn)展分析。在圖5.22中可以看到整個負(fù)載由3個頁面懇求組成，其中有一個懇求一直在0.8秒以內(nèi)，而另外2個懇求時間較長并且有上升趨勢。圖5.22 Web Page Diagnostics然后經(jīng)過Select Page to Break Down命令選擇詳細(xì)的Page來獲得每個懇求的相關(guān)詳細(xì)信息。這里選擇創(chuàng)建用戶的“172.168x?createuser=1懇求進(jìn)展分析。稍后可以在圖5.23中看到創(chuàng)建用戶呼應(yīng)時間的變化，隨著時間的增長呼應(yīng)時間從2.6

37、秒上升到了3.9秒，并且在7分30秒時大幅下滑，回到2.6秒左右。圖5.23 Web Page Diagnostics對用戶注冊頁面細(xì)分在Diagnostics options選項中提供了以下4大塊功能。Download Time(下載時間分析)這里可以得到組成頁面的每個懇求下載時間。在圖5.24中可以看到創(chuàng)建用戶的操作由4個懇求組成，其中導(dǎo)致注冊用戶較慢的主要緣由是注冊完成后需求等待兩秒鐘再刷新至論壇首頁，而非注冊用戶本身需求耗費(fèi)的時間。首頁刷新慢也只是由于Client(客戶端)需求耗費(fèi)較多時間，同時Receive(接納)的時間也有一定的影響。圖5.24 Web Page Diagnosti

38、cs Download TimeComponent(Over time)(各模塊的時間變化)這里列出組成頁面的每個元素，以及隨著時間的變化所帶來的呼應(yīng)時間變化。經(jīng)過這個功能可以分析呼應(yīng)時間變長是由于頁面生成慢，還是由于圖片資源下載慢。在圖5.25中可以發(fā)現(xiàn)隨著時間的添加，首頁的處置時間(最上面的一根線)從0.5秒上升到了最大值16秒，而注冊用戶呼應(yīng)時間幾乎沒有上升。圖5.25 Web Page Diagnostics Component(Over Time)Download Time(Over time)(模塊下載時間)這里提供了針對每個組成頁面元素的時間組成部分分析，方便確認(rèn)該元素的處置時間

39、組成部分。在圖526中可以發(fā)現(xiàn)首頁懇求的下載時間主要耗費(fèi)在Client上，而7分30秒之前Recevie所耗費(fèi)的時間在逐漸變長。圖5.26 Web Page Diagnostics Download Time(Over Time)Time to First Buffer(Over time)(模塊時間分類)這里會列出該元素所運(yùn)用的時間分配比例，是受Network Time影響的多還是ServerTime影響的多。在圖5.27中可以看出，對于首頁刷新的呼應(yīng)時間來說，主要是NetworkTime網(wǎng)絡(luò)上耗費(fèi)的時間，而Server Time效力器端的處置是非常優(yōu)秀的。ServerTime是指效力器對該

40、頁面的處置時間；Network Time是指網(wǎng)絡(luò)上的時間開銷。圖5.27 WebPage Diagnostics Time to First Buffer(Over time)經(jīng)過這4個分析圖，我們可以了解到對于事務(wù)的呼應(yīng)時間來說，效力器的處置時間并不是組成呼應(yīng)時間的主要部分，而網(wǎng)絡(luò)問題通常會占用超越70的時間，經(jīng)過Web Page Diagnostics可以準(zhǔn)確分析呼應(yīng)時間，防止由于網(wǎng)絡(luò)延遲或者帶寬問題而影響對呼應(yīng)時間的分析和瓶頸定位。在LoadRunner的安裝目錄下找到LRAnalysis80.ini文件，在其中的WPB下添加SURLSize=255，另外還需求修正loader2.mdb

41、文件，將其中Breakdown-map表中的EventName的屬性長度從50修正為255，在以后場景運(yùn)轉(zhuǎn)結(jié)果的報告中就可以顯示最長為255字符的途徑稱號了。Page Download Time Breakdown(頁面呼應(yīng)時間組成分析)這張圖中顯示了每個頁面呼應(yīng)時間的組成分析，一個頁面的呼應(yīng)時間普通由以下內(nèi)容組成：Client Time客戶端閱讀器接納所需求運(yùn)用的時間，可以不用思索。Connections Time銜接效力器所需求的時間，越小越好。DNS Resolution Time經(jīng)過DNS效力器解析域名所需求的時間，解析遭到DNS效力器的影響，越小越好。Error Time效力器前往錯

42、誤呼應(yīng)時間，這個時間反映了效力器處置錯誤的速度，普通是Web效力器直接前往的，包含了網(wǎng)絡(luò)時間和Web效力器前往錯誤的時間，該時間越小越好。First Buffer Time銜接到效力器，效力器前往第一個字節(jié)所需求的時間，反映了系統(tǒng)對于正常懇求的處置時間開銷，包含網(wǎng)絡(luò)時間和效力器正常處置的時間，該時間越小越好。FTP Authentication Time FTP認(rèn)證時間，這是進(jìn)展FTP登錄等操作所需求耗費(fèi)的認(rèn)證時間，越短越好。Receive Time接受數(shù)據(jù)的時間，這個時間反映了帶寬的大小，帶寬越大，下載時間越短。SSL Handshaking TimeSSL加密握手的時間。而Analysis

43、在這里會分析得到頁面懇求的組成比例圖，便于分析頁面時間浪費(fèi)在哪些過程中。在圖5.28中可以看到各個頁面懇求的呼應(yīng)時間組成情況，相對于00的首頁懇求，時間主要浪費(fèi)在Client上。圖5.28 Page Download Time BreakdownPage Download Time Breakdown(Over Time)(頁面組成部分時間)這里提供了隨著時間的變化一切懇求的呼應(yīng)時間變化過程。這里會將整個負(fù)載過程中每個頁面的每個時間組成部分都做成單獨(dú)的時間線，以便分析在不同的時間點(diǎn)上組成該頁面的各個懇求時間是如何變化的。在圖5.29中可以看到大多數(shù)頁面的呼應(yīng)時間是比較穩(wěn)定的，其中首頁刷新變動較

44、大。圖529 Page Download Time Breakdown(Over Time)首先找到變化最明顯或者呼應(yīng)時間最高的頁面，隨后再針對這個頁面進(jìn)展進(jìn)一步的分析了解時間偏長或者變化較快的緣由。Time to First Buffer Breakdown(頁面懇求組成時間)這里提供了組成頁面時間懇求的比例闡明(客戶端時間/效力器時間)，經(jīng)過這個圖，我們可以直觀地了解到整個頁面的處置是在效力器端耗費(fèi)的時間長，還是在客戶端耗費(fèi)的時間長，從而分析得到系統(tǒng)的性能問題是在前端還是在后端。在圖5.30中可以看出對于整個負(fù)載來說，網(wǎng)絡(luò)或客戶端的時間開銷占了絕大多數(shù)。Time to First Buff

45、er Breakdown(Over Time)(基于時間的頁面懇求組成分析)和圖530不同的是，這里給出了在整個負(fù)載過程中，每一個懇求的Server Time和Client Time隨著時間變化的趨勢，可以方便定位呼應(yīng)時間隨著時間變化的緣由究竟是由于客戶端變化導(dǎo)致的還是由于效力器端變化導(dǎo)致的。圖530 Time to First Buffer Breakdown在圖531中可以看到對于用戶注冊操作，網(wǎng)絡(luò)上的時間變化比效力器上的時間變化要猛烈。圖5.31 Time to First Buffer Breakdown(Over Time)5.3.6 Network Monitor(網(wǎng)絡(luò)監(jiān)控)假設(shè)在

46、Controller中添加了Network Delay Time監(jiān)控后會出現(xiàn)該數(shù)據(jù)圖。這個功能很好但并不是非常直觀和方便，建議運(yùn)用第三方專門的路由分析工具進(jìn)展網(wǎng)絡(luò)延遲和途徑分析。Network Delay Time這里會給出從監(jiān)控機(jī)至目的主機(jī)的平均網(wǎng)絡(luò)延遲變化情況。在圖532中可以看到網(wǎng)絡(luò)延遲從240毫秒逐漸減少到26毫秒，最后上升到340毫秒。圖532 Network Delay TimeNetwork Sub-Path Time這里給出從監(jiān)控機(jī)至目的機(jī)各個網(wǎng)絡(luò)途徑的平均時間。當(dāng)客戶端在銜接一個遠(yuǎn)程效力器時，途徑并不是獨(dú)一的，遭到路由器的路由選擇，能夠會選擇不同的途徑最終訪問到效力器。在圖5

47、33中列出了從監(jiān)控效力器至目的效力器所閱歷的途徑，以及每個途徑上的網(wǎng)絡(luò)延遲。圖5.33 Network Sub-Path timeNetwork Segment Delay Time這里給出各個途徑上的各個節(jié)點(diǎn)網(wǎng)絡(luò)延遲情況。和圖533不同的地方在于，這里給出的是路由器和路由器之間的網(wǎng)絡(luò)延遲情況，針對銜接而不是途徑。圖534中給出了路由器和路由器之間的網(wǎng)絡(luò)延遲變化情況，以便于分析影響整個網(wǎng)絡(luò)時間的緣由及節(jié)點(diǎn)。圖5.34 Network Segment Delay Time5.3.7 Resources(資源監(jiān)控)資源包括很多種，在Analysis中監(jiān)控的都是各種系統(tǒng)的計數(shù)器，這些計數(shù)器反映了系統(tǒng)

48、中硬件或者軟件的運(yùn)轉(zhuǎn)情況，經(jīng)過它可以發(fā)現(xiàn)系統(tǒng)瓶頸。System Resources(系統(tǒng)資源)這里給出了對操作系統(tǒng)計數(shù)器的監(jiān)控，列出了在負(fù)載過程中系統(tǒng)的各種資源數(shù)據(jù)是如何變化的，該圖需求在場景中設(shè)置了對應(yīng)系統(tǒng)的監(jiān)控后才出現(xiàn)。Database Server Resources(數(shù)據(jù)庫資源)這里給出了數(shù)據(jù)庫的相關(guān)資源在負(fù)載過程中的變化情況。Web Server Resources(Web效力器資源)這里給出了Web效力器資源在負(fù)載過程中的變化情況。對于各種資源類的圖來說，最困難的是了解各個計數(shù)器的含義。好比體檢時會涉及血液化驗，當(dāng)一張血液化驗單放在他面前時，普通用戶是無法了解化驗結(jié)果數(shù)據(jù)所反映的含

49、義，如今通常會在化驗報告單上簡單引見各個檢查工程的含義，紅細(xì)胞普通是在什么范圍內(nèi)，假設(shè)少了闡明貧血。當(dāng)進(jìn)展性能瓶頸定位時，必需掌握常見各種計數(shù)器的含義和能夠?qū)е略摻Y(jié)果的緣由。計數(shù)器分析接著引見一下各種在性能測試中需求監(jiān)控的常見計數(shù)器稱號及其含義和出現(xiàn)瓶頸的特征，供大家參考，更為詳細(xì)的內(nèi)容請參考各種運(yùn)用的公用調(diào)優(yōu)手冊和計數(shù)器手冊。如何獲得硬件計數(shù)器瓶頸或者各種計數(shù)器瓶頸數(shù)據(jù)?可以先經(jīng)過第三方工具對系統(tǒng)進(jìn)展負(fù)載，監(jiān)控在該負(fù)載下各個計數(shù)器的最高值是多少。當(dāng)用LoadRunner進(jìn)展負(fù)載時，假設(shè)該計數(shù)器到達(dá)該數(shù)據(jù)，那么可以闡明這個計數(shù)器出現(xiàn)了瓶頸。例如：經(jīng)過磁盤工具對物理磁盤進(jìn)展壓力測試，在這個過程中

50、可以監(jiān)控到物理磁盤的讀寫速度計數(shù)器峰值為x。當(dāng)我們用LoadRunner進(jìn)展負(fù)載時，假設(shè)物理磁盤讀寫計數(shù)器數(shù)據(jù)逐漸變大且最終到達(dá)X，就可以闡明物理磁盤出現(xiàn)讀寫瓶頸。CPU監(jiān)控常用的計數(shù)器及含義如表51所示。表5.1 CPU常用計數(shù)器內(nèi)存監(jiān)控常用的計數(shù)器及含義如表52所示。表52內(nèi)存常用計數(shù)器物理磁盤監(jiān)控常用的計數(shù)器及含義如表5_3所示。表53物理磁盤常用計數(shù)器線程監(jiān)控常用的計數(shù)器及含義如表54所示。表54線程常用計數(shù)器進(jìn)程監(jiān)控常用的計數(shù)器及含義如表55所示。表55進(jìn)程常用計數(shù)器SQL Server監(jiān)控常用的計數(shù)器及含義如表56所示。表5.6 SQL Server常用計數(shù)器 Web Servic

51、e Cache效力緩存監(jiān)控常用的計數(shù)器及含義如表57所示。表57效力緩存常用計數(shù)IIS監(jiān)控常用的計數(shù)器及含義如表58所示。表5811$常用計數(shù)器網(wǎng)絡(luò)監(jiān)控常用的計數(shù)器及含義如表59所示。表59網(wǎng)絡(luò)常用計數(shù)器ASP.NET監(jiān)控常用的計數(shù)器及含義如表510所示。表5.10 ASP.NET常用計數(shù)器Apache監(jiān)控常用的計數(shù)器及含義如表511所示。表511Apache常用計數(shù)器MySQL監(jiān)控常用的計數(shù)器及含義如表512所示。表5.12 MySQL常用計數(shù)器Oracle監(jiān)控常用的計數(shù)器及含義如表513所示。表513 Oracle常用計數(shù)器WebLogic監(jiān)控常用的計數(shù)器及含義如表514所示。表514 W

52、ebLogic常用計數(shù)器5.4 圖設(shè)置與操作在Analysis中經(jīng)常需求和各種圖打交道，那么我們需求對圖的常見功能設(shè)置有所了解，在圖上可以單擊鼠標(biāo)右鍵翻開設(shè)置菜單，對圖形進(jìn)展一定的設(shè)置。SetFilterGroupBy(圖的過濾規(guī)那么設(shè)置)不同圖的設(shè)置是不同的，主要是根據(jù)某些屬性進(jìn)展一定的過濾，來方便顯示。SetGranularity(圖的采樣點(diǎn)間距)Analysis會自動根據(jù)場景運(yùn)轉(zhuǎn)的時間來設(shè)置數(shù)據(jù)采樣點(diǎn)的間距，單位為秒。采樣點(diǎn)越小，越能反映數(shù)據(jù)微小的變化；而采樣點(diǎn)越大，那么能反映系統(tǒng)在大趨勢上的表現(xiàn)。View Cursor(翻開鼠標(biāo)指針)為鼠標(biāo)在圖中添加橫向和縱向的標(biāo)尺，方便了解鼠標(biāo)所在位

53、置的橫坐標(biāo)和縱坐標(biāo)。View Raw Data(翻開圖所對應(yīng)的數(shù)據(jù))Comments(注釋)在圖中添加注釋，便于闡明某些問題。Clear Display Options(去掉一切的顯示選項)該選項可以回到最原始的數(shù)據(jù)圖方式，去掉一切的過濾和顯示設(shè)置。Display Options(顯示方式選項)設(shè)置圖的顯示方式，經(jīng)過這個選項可以將圖調(diào)整得更加美觀，例如將圖轉(zhuǎn)化為3D方式或調(diào)整線條顏色及背景顏色等。5.4.1 Merge Graphs (合并圖)當(dāng)?shù)玫搅讼嚓P(guān)圖形，如何分析圖和圖之間的關(guān)系呢?MergeGraphs提供了一種將圖和圖合并的功能，經(jīng)過這個功能可以直觀地獲得一個數(shù)據(jù)和另外一個數(shù)據(jù)的相互

54、影響關(guān)系。在RunningVusers圖中，單擊鼠標(biāo)右鍵，在菜單中選擇MergeGraphs，如圖535所示。Merge的方式有3種：Overlay、Tile、Correlate，如圖536所示。這3種合并方法可以協(xié)助 我們對測試結(jié)果進(jìn)展分析，了解圖和圖之間的影響關(guān)系。Overlay基于Overlay合并方式，就是將兩張圖經(jīng)過x軸進(jìn)展覆蓋合并。例如將RunningVusers和AverageTransactionResponseTime進(jìn)展Overlay合并，如圖537所示。 圖5.35 Merge Graphs 圖5.36 Merge方式設(shè)置圖5.37 Overlay的Merge方式經(jīng)過這張

55、圖可以得到用戶增長的過程是如何影響事務(wù)平均時間的，從而發(fā)現(xiàn)瓶頸出現(xiàn)的時間。TileTile的方式和Overlay的方式非常接近，只是將兩張圖的y軸分了上下兩部分，不做重疊。將Running Vusers和Hits per Second進(jìn)展Tile合并，如圖538所示。圖5.38 Tile的Merge方式經(jīng)過這個合并，可以看到隨著用戶數(shù)量添加每秒點(diǎn)擊量的變化過程，從而了解在當(dāng)前負(fù)載下系統(tǒng)接受的點(diǎn)擊量峰值。相對于Overlay方式，兩張圖的線條不會重疊在一同，看起來更加清楚。Correlate這個合并比較復(fù)雜，首先將主圖的Y軸變?yōu)閤軸，而被合并圖的y軸依然保管為y軸，按照各圖本來的時間關(guān)系進(jìn)展合并

56、構(gòu)成新圖。例如這里將Running Vusers和Transactions per Second兩張圖進(jìn)展Correlate合并，如圖539所示。圖539Correlate的Merge方式系統(tǒng)將Running Vusers圖的Y軸作為新圖的x軸，將Transactions per Second圖的y軸作為新圖的y軸。在經(jīng)過Correlate方式合并后的圖中，可以更加明晰地看出用戶變化導(dǎo)致處置才干的變化過程，斜率越大闡明影響越大，方便快速定位在何種負(fù)載下系統(tǒng)呼應(yīng)時間可以穩(wěn)定，而在何種負(fù)載下呼應(yīng)時間會大幅上升。經(jīng)過這幾種常見的Merge方法，可以將相關(guān)計數(shù)器得到的圖進(jìn)展合并分析，找出系統(tǒng)性能的瓶頸

57、。由于系統(tǒng)瓶頸的定位需求大量的相關(guān)知識，對于一個初級性能測試工程師來說，并不要求有性能結(jié)果分析和性能瓶頸定位的才干。初級性能測試工程師可以將數(shù)據(jù)整理后提交給工程經(jīng)理、網(wǎng)絡(luò)或數(shù)據(jù)庫管理員，讓他們協(xié)助 他分析數(shù)據(jù)，并確認(rèn)及完成性能調(diào)優(yōu)任務(wù)。5.4.2 Auto Correlate(自動定位瓶頸)Auto Correlate提供了自動分析趨勢影響的功能，經(jīng)過它可以方便地找出哪些數(shù)據(jù)之間有明顯的相互依賴性，經(jīng)過圖和圖之間的關(guān)系確認(rèn)系統(tǒng)資源和負(fù)載相互影響的關(guān)系。首先找到需求自動關(guān)聯(lián)的圖，右鍵翻開Auto Correlate菜單。例如選擇從Running Vusers圖上做自動關(guān)聯(lián)，如圖540所示。彈出自

58、動關(guān)聯(lián)窗口，如圖541所示。我們需求進(jìn)展以下設(shè)置。1Time Range設(shè)置關(guān)聯(lián)的時間范圍標(biāo)簽。Suggest Time Range by提供了自動關(guān)聯(lián)的范圍參考，可以選擇Trend基于趨勢或者選擇Feature基于特征兩種方式。這兩種方式可以自動選擇關(guān)聯(lián)的范圍，Trend完好包含一切值得留意、分析的趨勢，而Feature那么是其間一個單獨(dú)的片段。例如這里選擇Feature，如圖542所示。 圖5.40 Auto Correlate 圖5.41 Auto Correlate設(shè)置圖5.42 Auto Correlate設(shè)置基于Feature特征的時間方式右側(cè)的豎線就會換到6分鐘的位置，由于從0分

59、到6分是用戶負(fù)載上升的階段，這個階段的特征就是添加。經(jīng)過單擊Next按鈕可以切換到下一個特征，下一個特征是6分40秒至7分04秒的負(fù)載下降階段，如圖5.43所示。圖5.43 Auto Correlate設(shè)置基于Feature特征的時間方式切換可以經(jīng)過拖動圖中的兩根豎線來確定關(guān)聯(lián)的范圍或直接修正From后的時間來調(diào)整關(guān)聯(lián)的范圍。這樣就確認(rèn)了希望關(guān)聯(lián)的時間范圍，接著需求設(shè)置被關(guān)聯(lián)的對象。2Correlation Options切換到Correlation Options標(biāo)簽，這里列出了一切和當(dāng)前圖可以進(jìn)展關(guān)聯(lián)的對象，默許選擇了3個資源圖，用戶也可以自行設(shè)置需求關(guān)聯(lián)的圖，另外可以在Data Inte

60、rval中設(shè)置數(shù)據(jù)點(diǎn)的間隔和Output中的輸出情況，如圖544所示。圖5.44 Auto Correlate關(guān)聯(lián)選項Data Interval是指自動關(guān)聯(lián)的數(shù)據(jù)間隔，默以為5秒鐘，也可以手工設(shè)定關(guān)聯(lián)的數(shù)據(jù)間隔。間隔的時間設(shè)置越小得出的關(guān)聯(lián)匹配度越準(zhǔn)確。Output是對輸出關(guān)結(jié)合果的設(shè)置，可以選擇設(shè)置顯示和被關(guān)聯(lián)圖匹配值最高的5個對象，也可以設(shè)置顯示一切和被關(guān)聯(lián)圖匹配值大于50的對象。這里修正Select measurement categories選擇對象為Hits per Second，其他選項堅持默許值，確定后得到最終的自動關(guān)結(jié)合果，如圖545所示。圖5.45 Auto Correlat