性能測(cè)試方法及分析報(bào)告方法

標(biāo)準(zhǔn)文案標(biāo)準(zhǔn)文案大全大全性能測(cè)試方法及分析方法一、性能測(cè)試簡(jiǎn)介什么是軟件性能性能是軟件產(chǎn)品的一種特性，可以用時(shí)間來(lái)進(jìn)展度量。性能的準(zhǔn)時(shí)性用響應(yīng)時(shí)間或者吞吐量來(lái)衡量。響應(yīng)時(shí)間是對(duì)懇求作出響應(yīng)所需要的時(shí)間。OK按鈕后2應(yīng)時(shí)間。〔Web述系統(tǒng)的性能，而對(duì)非交互式應(yīng)用〔嵌入式系統(tǒng)或是銀行等的業(yè)務(wù)處理系統(tǒng)〕而言，響應(yīng)時(shí)間是指系統(tǒng)對(duì)大事產(chǎn)生響應(yīng)所需要的時(shí)間。品的開(kāi)發(fā)人員也關(guān)注軟件性能，下面將從3用戶視角的軟件性能Web開(kāi)頭到應(yīng)用系統(tǒng)把本次操作的結(jié)果以用戶能覺(jué)察的方式呈現(xiàn)出來(lái)1.1以一個(gè)Web發(fā)出懇求 懇求應(yīng)用效勞器 DB效勞器用戶用戶感受到響應(yīng)

應(yīng)用界面呈現(xiàn)

返回?cái)?shù)據(jù)呈現(xiàn)時(shí)間 系統(tǒng)響應(yīng)時(shí)間1.1Web必需要說(shuō)明的是，用戶所體會(huì)到的“響應(yīng)時(shí)間”既有客觀的成分，也有主觀的成分。例〔順便說(shuō)一下，這種技巧是在C/S。1.2.1節(jié)對(duì)“響應(yīng)時(shí)間”的解釋。治理員視角的軟件性能外，他還會(huì)關(guān)心和系統(tǒng)狀態(tài)相關(guān)的信息。例如，治理員已經(jīng)知道，在并發(fā)用戶數(shù)為100時(shí)，A8CPU了最大值？是否還有可用的內(nèi)存？應(yīng)用效勞器的狀態(tài)如何？我們?cè)O(shè)置的JVM可用內(nèi)存是否足夠？數(shù)據(jù)庫(kù)的狀況如何？是否還需要進(jìn)展一些調(diào)整？這些問(wèn)題一般的用戶并不關(guān)心不在他們的體驗(yàn)范圍之內(nèi)；但對(duì)治理員來(lái)說(shuō)，要保證系統(tǒng)的穩(wěn)定運(yùn)行和持續(xù)的良好性能，就必需關(guān)心這些問(wèn)題。況制定治理措施，在系統(tǒng)消滅打算之外的用戶增長(zhǎng)等緊急狀況的時(shí)候能夠馬上制定相應(yīng)措施，進(jìn)展快速的處理；此外，治理員可能還會(huì)關(guān)心系統(tǒng)在長(zhǎng)時(shí)間的運(yùn)行中是否足夠穩(wěn)定，是否能夠不連續(xù)地供給業(yè)務(wù)效勞等。題。1-1治理員關(guān)心的問(wèn)題軟件性能描述效勞器的資源使用狀況合理嗎治理員關(guān)心的問(wèn)題軟件性能描述效勞器的資源使用狀況合理嗎資源利用率應(yīng)用效勞器和數(shù)據(jù)庫(kù)的資源使用狀況合理嗎資源利用率系統(tǒng)是否能夠?qū)崿F(xiàn)擴(kuò)展系統(tǒng)可擴(kuò)展性系統(tǒng)最多能支持多少用戶的訪問(wèn)？系統(tǒng)最大的業(yè)務(wù)處理系統(tǒng)容量量是多少系統(tǒng)性能可能的瓶頸在哪里系統(tǒng)可擴(kuò)展性更換哪些設(shè)備能夠提高系統(tǒng)性能系統(tǒng)可擴(kuò)展性7×24系統(tǒng)穩(wěn)定性開(kāi)發(fā)視角的軟件性能等治理員關(guān)心的內(nèi)容，由于這些也是產(chǎn)品需要面對(duì)的用戶〔特別的用戶。但對(duì)開(kāi)發(fā)人員來(lái)的性能表現(xiàn)到底是由于系統(tǒng)架構(gòu)選擇的不合理還是由于代碼實(shí)現(xiàn)的問(wèn)題引起？由于數(shù)據(jù)庫(kù)設(shè)計(jì)的問(wèn)題引起？抑或是由于系統(tǒng)的運(yùn)行環(huán)境引發(fā)？是否存在由于內(nèi)存處理等問(wèn)題引起的系統(tǒng)故障？因此，對(duì)開(kāi)發(fā)人員來(lái)說(shuō)，單純獲知系統(tǒng)性能“好”或者“不好”的評(píng)價(jià)并沒(méi)有太大的意1-21-2開(kāi)發(fā)人員關(guān)注的性能問(wèn)題開(kāi)發(fā)人員關(guān)心的問(wèn)題開(kāi)發(fā)人員關(guān)心的問(wèn)題問(wèn)題所屬層次架構(gòu)設(shè)計(jì)是否合理系統(tǒng)架構(gòu)數(shù)據(jù)庫(kù)設(shè)計(jì)是否存在問(wèn)題數(shù)據(jù)庫(kù)設(shè)計(jì)代碼是否存在性能方面的問(wèn)題代碼系統(tǒng)中是否有不合理的內(nèi)存使用方式代碼系統(tǒng)中是否存在不合理的線程同步方式設(shè)計(jì)與代碼系統(tǒng)中是否存在不合理的資源競(jìng)爭(zhēng)設(shè)計(jì)與代碼總結(jié)以上我們描述了3用戶對(duì)性能的理解屬于“用戶視角〔包括設(shè)計(jì)人員〕自然就是從“開(kāi)發(fā)視角”來(lái)關(guān)注軟件性能了。用戶的角度來(lái)說(shuō)，表現(xiàn)為軟件系統(tǒng)對(duì)用戶操作的響應(yīng)時(shí)間；在系統(tǒng)或是治理員的關(guān)注層面，和引起性能問(wèn)題的關(guān)鍵緣由。軟件性能的幾個(gè)術(shù)語(yǔ)性能計(jì)數(shù)器，在使用性能測(cè)試工具進(jìn)展測(cè)試時(shí)，還會(huì)接觸到“思考時(shí)間ThinkTim”的概念，那么，這些術(shù)語(yǔ)的精準(zhǔn)含義到底是什么呢？本節(jié)重點(diǎn)介紹以上的各個(gè)術(shù)語(yǔ)。響應(yīng)時(shí)間1.11.1.1圖1.1〔響應(yīng)時(shí)間Web性能測(cè)試中，我們并不關(guān)注“呈現(xiàn)時(shí)間表現(xiàn)，例如，一臺(tái)內(nèi)存缺乏的客戶端機(jī)器在處理簡(jiǎn)潔頁(yè)面的時(shí)候，其呈現(xiàn)時(shí)間可能就很長(zhǎng)，應(yīng)時(shí)間”和“響應(yīng)時(shí)間1.2描述了一個(gè)Web中可以看到，頁(yè)面的響應(yīng)時(shí)間可被分解為“網(wǎng)絡(luò)傳輸時(shí)間〔N1+N2+N3+N〕A1+A2+A，而“應(yīng)用延遲時(shí)間”又可以分解為“數(shù)據(jù)庫(kù)延遲時(shí)間〔A〕和“應(yīng)用效勞A1+A。之所以要對(duì)響應(yīng)時(shí)間進(jìn)展這些分解，主要目的是為了能更好定位能問(wèn)題的定位。1.2Web用戶主觀顏色，也就是說(shuō)，響應(yīng)時(shí)間的“長(zhǎng)”和“短”沒(méi)有確定的區(qū)分。例如，對(duì)一個(gè)電子商務(wù)網(wǎng)站來(lái)說(shuō)，在美國(guó)和歐洲，一個(gè)普遍被承受的響應(yīng)時(shí)間標(biāo)準(zhǔn)為2/5/10秒，也就是說(shuō)，在2秒之內(nèi)給客戶響應(yīng)被用戶認(rèn)為是“格外有吸引力的5內(nèi)響應(yīng)客戶被認(rèn)為是“比較不錯(cuò)的10秒是客戶能承受的響應(yīng)的上限。2小時(shí)以上進(jìn)行數(shù)據(jù)的錄入，當(dāng)用戶單擊“提交”按鈕后，即使系統(tǒng)在20分鐘后才給出“處理成功”的操作來(lái)說(shuō)，20因此，在進(jìn)展性能測(cè)試時(shí)試人員自己的設(shè)想來(lái)打算。并發(fā)用戶數(shù)在闡述這個(gè)術(shù)語(yǔ)之前，先來(lái)看看為什么在性能測(cè)試中需要關(guān)注這個(gè)“并發(fā)用戶數(shù)弄清楚會(huì)有多少用戶會(huì)在同一個(gè)時(shí)間段內(nèi)訪問(wèn)被測(cè)試的系統(tǒng)就是我們說(shuō)的并發(fā)用戶數(shù)的一個(gè)概念，這種并發(fā)的概念通常在性能測(cè)試〔PerformanceTesting〕C/S或是B/S應(yīng)用來(lái)說(shuō)，系統(tǒng)的性能表現(xiàn)毫無(wú)疑問(wèn)地主要由“效勞端”打算。在什么時(shí)候“效勞端”會(huì)承受最大的壓力，或者說(shuō)，在什么時(shí)候“效勞端”表現(xiàn)為最差的性能呢？毫無(wú)疑問(wèn)，確定是在大量用戶同時(shí)對(duì)這個(gè)系統(tǒng)進(jìn)展訪問(wèn)的時(shí)候。為了說(shuō)明這個(gè)“同時(shí)1.。1.3用排球擊打墻面圖1.3用“排球擊打墻面”說(shuō)明這種“同時(shí)描述的是同時(shí)向客戶端發(fā)出懇求的客戶，該概念一般結(jié)合并發(fā)測(cè)試〔ConcurrencyTesting〕使用，表達(dá)的是效勞端承受的最大并發(fā)訪問(wèn)數(shù)。下面我們用一個(gè)更接近實(shí)際的例子來(lái)說(shuō)明這兩個(gè)并發(fā)概念之間的不同。1.4應(yīng)用界面效勞器VU應(yīng)用界面效勞器VUVU2

VUG1.4實(shí)際應(yīng)用系統(tǒng)用戶的懇求執(zhí)行某些操作，然后將結(jié)果返回給用戶。從用戶的角度來(lái)看，在一個(gè)相當(dāng)長(zhǎng)的時(shí)間段內(nèi)〔例如1天念就是前面爭(zhēng)論的業(yè)務(wù)并發(fā)用戶數(shù)。的運(yùn)行過(guò)程中，把整個(gè)運(yùn)行過(guò)程劃分為離散的時(shí)間點(diǎn)，在每個(gè)點(diǎn)上，都有一個(gè)“同時(shí)向效勞壓力最大，資源承受的壓力也最大，在這種狀態(tài)下，可以考慮通過(guò)并發(fā)測(cè)試〔ConcurrencyTesting〕覺(jué)察系統(tǒng)中存在的并發(fā)引起的資源爭(zhēng)用等問(wèn)題。在實(shí)際的性能測(cè)試中，常常接觸到的與并發(fā)用戶數(shù)相關(guān)的概念還包括“并發(fā)用戶數(shù)”、“系統(tǒng)用戶數(shù)”和“同時(shí)在線用戶人數(shù)假設(shè)有一個(gè)OA2023OA用戶總數(shù)是2023名，這個(gè)概念就是“系統(tǒng)用戶數(shù)〔用一個(gè)全局變量計(jì)數(shù)全部已登錄的用戶，從在線統(tǒng)計(jì)功能中可以得到，最頂峰時(shí)有500人在線〔這個(gè)500就是一般所說(shuō)的“同時(shí)在線人數(shù)，那么，系統(tǒng)的并發(fā)用戶數(shù)是多少呢？依據(jù)我們對(duì)業(yè)務(wù)并發(fā)用戶數(shù)的定義，這500就是整個(gè)系統(tǒng)使用時(shí)最大的業(yè)務(wù)并發(fā)用戶數(shù)。固然，500500器承受的壓力。由于效勞器承受的壓力還與具體的用戶訪問(wèn)模式相關(guān)。例如，在這500個(gè)“同時(shí)使用系統(tǒng)”的用戶中，考察某一個(gè)時(shí)間點(diǎn)，在這個(gè)時(shí)間上，假設(shè)其中40%的用戶在饒有興致地看系統(tǒng)公告〔，20〔對(duì)用戶填寫(xiě)的表格來(lái)說(shuō)，只有在“提交”的時(shí)刻才會(huì)向效勞端發(fā)送懇求，填寫(xiě)過(guò)程是不對(duì)效勞端構(gòu)成壓力的，20〔也就是什么也沒(méi)有做，剩下的20%用戶在不停地從一個(gè)頁(yè)面跳轉(zhuǎn)到另一個(gè)頁(yè)面——在這種場(chǎng)景下，可以說(shuō)，只有20%不只取決于業(yè)務(wù)并發(fā)用戶數(shù)，還取決于用戶的業(yè)務(wù)場(chǎng)景。業(yè)務(wù)場(chǎng)景，一般可以通過(guò)對(duì)效勞器日志的分析得到。并發(fā)用戶數(shù)進(jìn)展?fàn)幷?，而且，為了便利，直接將業(yè)務(wù)并發(fā)用戶數(shù)稱為并發(fā)用戶數(shù)。那么，到底應(yīng)當(dāng)如何獲得測(cè)試人員關(guān)心的并發(fā)用戶數(shù)的具體數(shù)值呢？下面給出了一些用于估算并發(fā)用戶數(shù)的公式。nLCT 〔1〕CC3C

〔2〕loginsession的平均長(zhǎng)度；TOA應(yīng)用，考察的時(shí)間段長(zhǎng)度應(yīng)當(dāng)8公式2〕則給出了并發(fā)用戶數(shù)峰值的計(jì)算方式，其中，?C就是公式〔1〕中得到的平均的并發(fā)用戶數(shù)。該公式的得出是假設(shè)用戶的loginsession符合泊松分布而估算得到的。下面依據(jù)上述給出的方法進(jìn)展實(shí)例計(jì)算。OA30004004小時(shí)，在8則依據(jù)公式〕和公式2，可以得到：C=400×4/8=200200200+3×200

=242loginsession算這兩個(gè)值并不簡(jiǎn)潔。另外，考慮到用戶的業(yè)務(wù)操作存在確定的時(shí)間集中〔也就是說(shuō)，用戶對(duì)系統(tǒng)業(yè)務(wù)的訪問(wèn)往往不是平均分布在整個(gè)考察時(shí)間段內(nèi)時(shí)間段內(nèi)，承受公式〕和公式〕進(jìn)展計(jì)算照舊存在確定的偏差。我們給出對(duì)該公式使用的一些建議1個(gè)小時(shí)為考察時(shí)間的粒度，對(duì)一個(gè)OA8在的時(shí)間集中性的問(wèn)題。301日前夕會(huì)有大量用戶的訪問(wèn)……因此多考慮一些可能發(fā)生的場(chǎng)景，基于這些場(chǎng)景進(jìn)展估算。Web〔固然精度更差〕閱歷公式是：Cn10 〔3〕rC 〔4〕也就是說(shuō)，用每天訪問(wèn)系統(tǒng)用戶數(shù)的10%作為平均的并發(fā)用戶數(shù)，并發(fā)用戶數(shù)的最大值由并發(fā)用戶數(shù)乘上一個(gè)調(diào)整因子r得到，r2～3。公式〔3〕和公式〔4〕可以在要求不太嚴(yán)格的性能測(cè)試，或是只有很少數(shù)據(jù)支持分析的性能測(cè)試中使用。在本節(jié)的前面局部提到了“日志分析”方法。所謂“日志分析”方法是指通過(guò)對(duì)應(yīng)用效勞并發(fā)用戶訪問(wèn)數(shù)”數(shù)據(jù)。這種方式得到的數(shù)據(jù)準(zhǔn)確度和可信度都比較高，對(duì)于Internet用等無(wú)法估量用戶數(shù)量和用戶行為模式的應(yīng)用，這種方式最為可信。吞吐量吞吐量是指“單位時(shí)間內(nèi)系統(tǒng)處理的客戶懇求的數(shù)量/秒或是頁(yè)面數(shù)/秒來(lái)衡量，從業(yè)務(wù)的角度，吞吐量也可以用訪問(wèn)人數(shù)/天或是處理的業(yè)務(wù)數(shù)/節(jié)數(shù)/天來(lái)考察網(wǎng)絡(luò)流量。例如，對(duì)一個(gè)Web應(yīng)用系統(tǒng)來(lái)說(shuō)，從系統(tǒng)的處理力氣考慮，可以以頁(yè)面數(shù)/秒作為吞吐量的標(biāo)準(zhǔn)；對(duì)一個(gè)銀行的業(yè)務(wù)前臺(tái)系統(tǒng)來(lái)說(shuō)，可以以其處理的業(yè)務(wù)數(shù)/小時(shí)作為吞吐量的標(biāo)準(zhǔn)。在本章的開(kāi)頭局部，已經(jīng)爭(zhēng)論過(guò)，對(duì)于交互式應(yīng)用，用戶直接的體驗(yàn)是“響應(yīng)時(shí)間吐量”來(lái)描述我們對(duì)系統(tǒng)性能的期望可能更加合理。對(duì)于交互式應(yīng)用來(lái)說(shuō)，吞吐量指標(biāo)反映的是效勞器承受的壓力。在容量規(guī)劃的測(cè)試中，過(guò)程中，吞吐量指標(biāo)也有重要的價(jià)值，例如，Empirix80%是由于吞吐量的限制導(dǎo)致的。在對(duì)Web系統(tǒng)的性能測(cè)試過(guò)程中，吞吐量主要以懇求數(shù)〔單擊數(shù)/字節(jié)數(shù)/秒來(lái)表達(dá)，吞吐量指標(biāo)可以在兩個(gè)方面發(fā)揮作用：用于幫助設(shè)計(jì)性能測(cè)試場(chǎng)景，以及衡量性能測(cè)試場(chǎng)景是否到達(dá)了預(yù)期的設(shè)計(jì)目標(biāo)：在設(shè)計(jì)性能測(cè)試場(chǎng)景時(shí)，吞吐量可被用于幫助設(shè)計(jì)性能測(cè)試場(chǎng)景，依據(jù)估算的吞吐量數(shù)據(jù)，吞吐量可以衡量測(cè)試是否到達(dá)了預(yù)期的目標(biāo)。用于幫助分析性能瓶頸：吞吐量的限制是性能瓶頸的一種重要表現(xiàn)形式，因此，有針對(duì)性地對(duì)吞吐量設(shè)計(jì)測(cè)試，可以幫助盡快定位到性能瓶頸所在位置。例如，RBI〔RapidBottleneckIdentify〕方法就主要通過(guò)吞吐量測(cè)試覺(jué)察性能瓶頸。以不同方式表達(dá)的吞吐量可以說(shuō)明不同層次的問(wèn)題。例如，以字節(jié)數(shù)/秒方式表示的吞吐量主要受網(wǎng)絡(luò)根底設(shè)施、效勞器架構(gòu)、應(yīng)用效勞器制約；以單擊數(shù)/秒方式表示的吞吐量主要受應(yīng)用效勞器和應(yīng)用代碼的制約。到性能瓶頸的時(shí)候，吞吐量可以承受如下公式計(jì)算：FN其中，F(xiàn)表示吞吐量；N

R 〔5〕vuTvuVU〔VirtuaeUser，虛擬用戶〕的個(gè)數(shù)；RVUvu發(fā)出的懇求〔單擊〕數(shù)量；T表示性能測(cè)試所用的時(shí)間。但假設(shè)遇到了性能瓶頸，此時(shí)吞吐VU〔5〕給出的關(guān)系。常用于分析吞吐量的圖形是“吞吐量——VU1.5給出了兩個(gè)“吞吐量——VU從圖中可以看到，吞吐量在VU數(shù)量增長(zhǎng)到確定程度的時(shí)候產(chǎn)生了性能瓶頸。本文給出了一個(gè)例如。1.5“吞吐量——VU對(duì)同一個(gè)應(yīng)用進(jìn)展兩次不同的性能測(cè)試，測(cè)試A100個(gè)并發(fā)，每個(gè)VU1出一個(gè)懇求；測(cè)試B1000VU10A，測(cè)試〔頁(yè)/秒100×1/1=100B〔頁(yè)/秒1000×1/10=100，100。但從測(cè)試結(jié)果來(lái)看，執(zhí)行測(cè)試A50/秒消滅性能瓶頸，而測(cè)試B25/秒消滅性能瓶頸。性能計(jì)數(shù)器〔Counte是描述效勞器或操作系統(tǒng)性能的一些數(shù)據(jù)指標(biāo)系統(tǒng)來(lái)說(shuō)，使用內(nèi)存數(shù)MemoryInUsag，進(jìn)程時(shí)間TotalProcessTim〕的計(jì)數(shù)器。器只能表達(dá)系統(tǒng)性能的某一個(gè)方面，對(duì)性能測(cè)試結(jié)果的分析必需基于多個(gè)不同的計(jì)數(shù)器。與性能計(jì)數(shù)器相關(guān)的另一個(gè)術(shù)語(yǔ)是“資源利用率/總的資源可用量”形成資源利用率的數(shù)據(jù)，用以進(jìn)展各種資源使用的比較。10000Web效勞器的CPU占用率為68%，平均的內(nèi)存占用率為556855在性能測(cè)試中常用資源利用率進(jìn)展橫向的比照，例如，在進(jìn)展測(cè)試時(shí)會(huì)覺(jué)察，資源A的使用率到達(dá)了接近100%的數(shù)值，而其他的資源利用率都處于比較低的水平，則可以很清楚A要結(jié)合響應(yīng)時(shí)間變化曲線、系統(tǒng)負(fù)載曲線等各種指標(biāo)進(jìn)展分析。性能計(jì)數(shù)器是性能測(cè)試分析的主要參考值，本書(shū)的第3章對(duì)其進(jìn)展了具體的解釋說(shuō)明，并說(shuō)明白如何利用這些計(jì)數(shù)器分析系統(tǒng)性能瓶頸。思考時(shí)間思考時(shí)間ThinkTim，也被稱為“休眠時(shí)間等待一段時(shí)間，再發(fā)出下一個(gè)懇求。各個(gè)操作之間等待一段時(shí)間，表達(dá)在腳本中，具體而言，就是在操作之間放置一個(gè)Think的函數(shù)，使得腳本在執(zhí)行兩個(gè)操作之間等待一段時(shí)間。在測(cè)試腳本中思考時(shí)間表達(dá)為腳本中兩個(gè)懇求語(yǔ)句之間的間隔時(shí)間不同的測(cè)試工具供給了不同的函數(shù)或者方法來(lái)實(shí)現(xiàn)思考時(shí)間，本書(shū)附錄A中對(duì)思考時(shí)間進(jìn)展了的具體描述，另外，本書(shū)實(shí)踐篇也有一些使用思考時(shí)間的實(shí)際 例子。實(shí)，思考時(shí)間與迭代次數(shù)、并發(fā)用戶數(shù)和吞吐量之間存在確定的關(guān)系。公式〔5〕VUN、每個(gè)用戶發(fā)出懇求數(shù)RT的函數(shù)，而其中vuR又可以用時(shí)間T和用戶的思考時(shí)間T來(lái)計(jì)算：sTR 〔6〕Ts用公式〔5〕和公式〔6〕進(jìn)展化簡(jiǎn)運(yùn)算可得，吞吐量與N成正比，而與T成反比。vu s步驟：首先計(jì)算出系統(tǒng)的并發(fā)用戶數(shù)；統(tǒng)計(jì)出系統(tǒng)平均的吞吐量；統(tǒng)計(jì)出平均每個(gè)用戶發(fā)出的懇求數(shù)量；依據(jù)公式〔6〕計(jì)算出思考時(shí)間。4計(jì)算得出的思考時(shí)間為基準(zhǔn)，讓實(shí)際的思考時(shí)間在確定幅度內(nèi)隨機(jī)變動(dòng)。LoadRunner和SegueSilkPerformer等工具都支持以這種方式設(shè)置思考時(shí)間。最終要說(shuō)明的是“00”作為思考時(shí)間，以給要求。由于從業(yè)務(wù)的角度考慮，思考時(shí)間用于更真實(shí)地模擬用戶操作，設(shè)置思考時(shí)間為0，根本上不具有實(shí)際的業(yè)務(wù)含義。但在非交互式應(yīng)用的性能測(cè)試過(guò)程中，有時(shí)候確實(shí)會(huì)將思考時(shí)間設(shè)置為0，這時(shí)候是模擬一種盡可能大的壓力，爭(zhēng)論系統(tǒng)在巨大壓力下的表現(xiàn)?？梢哉f(shuō)，假設(shè)測(cè)試的目的是為了“驗(yàn)證應(yīng)用系統(tǒng)具有預(yù)期的力氣〔也就是所說(shuō)的“力氣驗(yàn)證”的應(yīng)用領(lǐng)域，就應(yīng)當(dāng)盡量模擬用戶在使用業(yè)務(wù)時(shí)的真實(shí)思考時(shí)間；假設(shè)目的是進(jìn)展更一般的爭(zhēng)論，例如“了解系統(tǒng)在壓力下的性能水平”或是“了解系統(tǒng)承受壓力的力氣”〔也就是所說(shuō)的“規(guī)劃力氣”的應(yīng)用領(lǐng)域，則可以承受0思考時(shí)間。二、性能測(cè)試方法論與方法簡(jiǎn)潔成為一種任憑的測(cè)試行為，而任憑進(jìn)展的性能測(cè)試很難取得實(shí)際的作用和預(yù)期的效果，因此本章將簡(jiǎn)潔介紹幾種常見(jiàn)的性能測(cè)試過(guò)程和方法，并著重介紹常用的性能測(cè)試方法。性能測(cè)試方法論SEISEI負(fù)載測(cè)試打算過(guò)程〔SEILoadTestingPlanningProcess〕是一個(gè)關(guān)注于負(fù)載測(cè)試打算的方法，其目標(biāo)是產(chǎn)生“清楚、易理解、可驗(yàn)證的負(fù)載測(cè)試打算SEI負(fù)載測(cè)試打算過(guò)程包括6個(gè)關(guān)注的區(qū)域AreSEI負(fù)載測(cè)試打算過(guò)程將以上述6個(gè)區(qū)域作為負(fù)載測(cè)試打算需要重點(diǎn)關(guān)注和考慮的內(nèi)容，其重點(diǎn)關(guān)注以下幾個(gè)方面的內(nèi)容：產(chǎn)環(huán)境上的實(shí)際性能表現(xiàn)，為了躲避這個(gè)風(fēng)險(xiǎn)，必需認(rèn)真設(shè)計(jì)測(cè)試環(huán)境。用戶分析：用戶是對(duì)被測(cè)應(yīng)用系統(tǒng)性能表現(xiàn)最關(guān)注和受影響最大的對(duì)象，因此，必需通過(guò)對(duì)用戶行為進(jìn)展分析，依據(jù)用戶行為模型建立用例和場(chǎng)景。用例：用例是用戶使用某種挨次和操作方式對(duì)業(yè)務(wù)過(guò)程進(jìn)展實(shí)現(xiàn)的過(guò)程，對(duì)負(fù)載測(cè)現(xiàn)性能問(wèn)題的風(fēng)險(xiǎn)等。SEISEI打算過(guò)程的一些關(guān)注內(nèi)容，而沒(méi)有能夠形成實(shí)際的可操作的過(guò)程。段，但由于性能測(cè)試自身的特別性〔例如，需要引入工具，分析階段相對(duì)重要，性能測(cè)試過(guò)程又不能完全套用功能測(cè)試過(guò)程。SEI完整的測(cè)試過(guò)程。RBIRBI〔RapidBottleneckIdentify〕方法是Empirix性能瓶頸的方法。該方法基于以下一些事實(shí)：覺(jué)察的80%系統(tǒng)的性能瓶頸都由吞吐量制約；并發(fā)用戶數(shù)和吞吐量瓶頸之間存在確定的關(guān)聯(lián)；承受吞吐量測(cè)試可以更快速定位問(wèn)題。RBI方法首先訪問(wèn)效勞器上的“小頁(yè)面”和“簡(jiǎn)潔應(yīng)用保持根本全都的增長(zhǎng)趨勢(shì)，通過(guò)不斷增加并發(fā)用戶數(shù)和吞吐量，觀看系統(tǒng)的性能表現(xiàn)。在確定具體的性能瓶頸時(shí)，RBI將性能瓶頸的定位依據(jù)一種“自上而下”的分析方式進(jìn)展分析，首先確定是由并發(fā)還是由吞吐量引發(fā)的性能表現(xiàn)限制，然后從網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)4RBI值得借鑒，但其也不是完整的性能測(cè)試過(guò)程。性能下降曲線分析法性能下降曲線實(shí)際上描述的是性能隨用戶數(shù)增長(zhǎng)而消滅下降趨勢(shì)的曲線/主要是指響應(yīng)時(shí)間。1.61.6一條典型的響應(yīng)時(shí)間性能下降曲線例如1.6單用戶區(qū)域——對(duì)系統(tǒng)的一個(gè)單用戶的響應(yīng)時(shí)間域可被用作基線或是benchmark。壓力區(qū)域——應(yīng)用“略微下降”的地方。典型的、最大的建議用戶負(fù)載是壓力區(qū)域第三步第四步第三步第四步的開(kāi)頭。性能拐點(diǎn)——性能開(kāi)頭“急劇下降”的點(diǎn)。頸產(chǎn)生的地方。拐點(diǎn)，通過(guò)識(shí)別不同的區(qū)間和拐點(diǎn)，從而為性能瓶頸識(shí)別和性能調(diào)優(yōu)供給依據(jù)。LoadRunner第一步打算測(cè)試測(cè)試設(shè)計(jì)VU腳本創(chuàng)立測(cè)試場(chǎng)景運(yùn)行測(cè)試場(chǎng)景分析結(jié)果其次步1.7給出了LoadRunner第一步打算測(cè)試測(cè)試設(shè)計(jì)VU腳本創(chuàng)立測(cè)試場(chǎng)景運(yùn)行測(cè)試場(chǎng)景分析結(jié)果其次步第五步第六步1.7LoadRunner第五步第六步用例的設(shè)計(jì)；創(chuàng)立VU腳本階段主要依據(jù)設(shè)計(jì)的用例創(chuàng)立腳本；創(chuàng)立測(cè)試場(chǎng)景階段主要進(jìn)展執(zhí)行，收集相應(yīng)數(shù)據(jù)；分析結(jié)果階段主要進(jìn)展結(jié)果分析和報(bào)告工作。LoadRunner供給的這共性能測(cè)試過(guò)程已經(jīng)涵蓋了性能測(cè)試工作的大局部?jī)?nèi)容，但由于該過(guò)程過(guò)于嚴(yán)密地與LoadRunner工具集成，沒(méi)有兼顧使用其他工具，或是用戶自行設(shè)計(jì)工具的需求，也不能被稱為是一個(gè)普適性的測(cè)試過(guò)程。另外，LoadRunner供給的該性能測(cè)試過(guò)程并未對(duì)打算測(cè)試階段、測(cè)試設(shè)計(jì)階段的具體行為、方法和目的進(jìn)展具體描述，因此該方法最多只能被稱為“使用LoadRunner進(jìn)展測(cè)試Segue圖1.8SegueSilkPerformerPerformanceTestingLifecycletry-checkSilkPerformer供給的性能測(cè)試過(guò)程從確定性能基線開(kāi)頭，通過(guò)單用戶對(duì)應(yīng)用的訪問(wèn)獵取性能取值的基線，然后設(shè)定可承受的性能目標(biāo)〔響應(yīng)時(shí)間，用不同的并發(fā)用戶數(shù)等重復(fù)進(jìn)展測(cè)試。Segue供給的這種性能測(cè)試方法格外適合性能調(diào)優(yōu)和性能優(yōu)化，通過(guò)不斷重復(fù)的try-check過(guò)程，可以逐一找到可能導(dǎo)致性能瓶頸的地方并對(duì)其進(jìn)展優(yōu)化。EvaluateEvaluateDevelopTestAssetsDevelopExploratoryRe-BenchBaseLine&BenchmarkTuneSystemAnalyzeResultsTestsValidateReg’sCriteriaMetCompleteProject1.8SegueSilkPerformer但Segue供給的這共性能測(cè)試過(guò)程模型存在與LoadRunner的性能測(cè)試過(guò)程同樣的問(wèn)題，出具體的活動(dòng)和目標(biāo)。性能測(cè)試的方法此外還存在其他的一些類型的性能測(cè)試方法。依據(jù)大范圍的性能測(cè)試的概念的界定，性能測(cè)試可包括如下幾種方法：性能測(cè)試PerformanceTestin；負(fù)載測(cè)試LoadTestin；壓力測(cè)試StressTestin；配置測(cè)試ConfigurationTestin；并發(fā)測(cè)試ConcurrencyTestin；牢靠性測(cè)試ReliabilityTestin；失效恢復(fù)測(cè)試FailoverTestin；性能測(cè)試〔PerformanceTesting〕性能測(cè)試〔PerformanceTesting〕方法是通過(guò)模擬生產(chǎn)運(yùn)行的業(yè)務(wù)壓力氣和使用場(chǎng)景組合，測(cè)試系統(tǒng)的性能是否滿足生產(chǎn)性能要求。PerformanceTesting是一種最常見(jiàn)的測(cè)試方法，通俗地說(shuō)，這種測(cè)試方法就是要在特定的運(yùn)行條件下驗(yàn)證系統(tǒng)的力氣狀況。這種方法的特點(diǎn)有：這種方法的主要目的是驗(yàn)證系統(tǒng)是否有系統(tǒng)宣稱具有的力氣。有的力氣。這種方法需要事先了解被測(cè)試系統(tǒng)典型場(chǎng)景，并具有確定的性能目標(biāo)。PerformanceTesting1005這種方法要求在已確定的環(huán)境下運(yùn)行。PerformanceTesting〔硬件設(shè)備、軟件環(huán)境、網(wǎng)絡(luò)條件、根底數(shù)據(jù)等〕都已經(jīng)確定。負(fù)載測(cè)試〔LoadTesting〕負(fù)載測(cè)試〔LoadTesting〕方法通過(guò)在被測(cè)系統(tǒng)上不斷增加壓力，直到性能指標(biāo)，例如“響應(yīng)時(shí)間”超過(guò)預(yù)定指標(biāo)或者某種資源使用已經(jīng)到達(dá)飽和狀態(tài)。這種測(cè)試放大可以找到系統(tǒng)的處理極限，為系統(tǒng)調(diào)優(yōu)供給數(shù)據(jù)。在某些狀況下，這種方法有時(shí)也被稱為可量性測(cè)試ScalabilityTestin。該方法有這樣一些特點(diǎn)：這種性能測(cè)試方法的主要目的是找到系統(tǒng)處理力氣的極限。LoadTesting方法通過(guò)“檢測(cè)-加壓-直到性能指標(biāo)超過(guò)預(yù)期”的手段，其主要目的是120個(gè)并發(fā)用戶訪問(wèn)”12100的性能指標(biāo)”一般會(huì)被定義為“響應(yīng)時(shí)間不超過(guò)10CPU65%”等指標(biāo)。這種性能測(cè)試方法需要在給定的測(cè)試環(huán)境下進(jìn)展與唯物壓力氣和典型場(chǎng)景，使得測(cè)試結(jié)果具有業(yè)務(wù)上的意義。LoadTesting方法由于涉及到“預(yù)定的性能指標(biāo)”等需要進(jìn)展比較的數(shù)據(jù)，也必需在給定的測(cè)試環(huán)境下進(jìn)展。另外，LoadTesting方法在“加壓”的時(shí)候，必需選擇典型場(chǎng)景，在增加壓力時(shí)保證這種壓力具有業(yè)務(wù)上的意義。用。

這種性能測(cè)試方法是一般用來(lái)了解系統(tǒng)的性能容量，或是協(xié)作性能調(diào)優(yōu)來(lái)使LoadTesting方法可以用來(lái)了解系統(tǒng)的性能容量〔系統(tǒng)在保證確定響應(yīng)時(shí)間的狀況下能夠允很多少并發(fā)用戶的訪問(wèn)差異。壓力測(cè)試〔StressTesting〕壓力測(cè)試〔StressTesting〕方法測(cè)試系統(tǒng)在確定飽和狀態(tài)下，例如CPU、內(nèi)存等在飽和使用狀況下，系統(tǒng)能夠處理的會(huì)話力氣，以及系統(tǒng)是否會(huì)消滅錯(cuò)誤。StressTesting這種性能測(cè)試方法的主要目的是檢查系統(tǒng)處于壓力狀況下時(shí)，應(yīng)用的表現(xiàn)。StressTesting方法通過(guò)增加訪問(wèn)壓力〔例如，增加并發(fā)的用戶數(shù)量等有無(wú)出錯(cuò)信息產(chǎn)生，系統(tǒng)對(duì)應(yīng)用的響應(yīng)時(shí)間等。一般狀況下，會(huì)把壓力設(shè)定為“CPU7570%以上”CPU和內(nèi)存使用率JVMCPU作為壓力的依據(jù)。這種性能測(cè)試方法一般用于測(cè)試系統(tǒng)的穩(wěn)定性。用壓力測(cè)試的方法考察系統(tǒng)的穩(wěn)定性是出于這樣的考慮題。配置測(cè)試〔ConfigurationTesting〕配置測(cè)試〔ConfigurationTesting〕方法通過(guò)對(duì)被測(cè)系統(tǒng)的軟/硬件環(huán)境的調(diào)整，了解各種不同環(huán)境對(duì)系統(tǒng)性能影響的程度，從而找到系統(tǒng)各項(xiàng)資源的最優(yōu)安排原則。這種方法具有以下的特定：這種性能測(cè)試方法的主要目的是了解各種不同因素對(duì)系統(tǒng)性能影響的程度而推斷出最值得進(jìn)展的調(diào)優(yōu)操作。的主要目的是了解各種因素對(duì)系統(tǒng)性能的影響程度，從而推斷出對(duì)性能影響最大的因素。這種性能測(cè)試方法一般在對(duì)系統(tǒng)性能狀況有初步了解后進(jìn)展。ConfigurationTesting的因素。這種性能測(cè)試方法一般用于性能調(diào)優(yōu)和規(guī)劃力氣。ConfigurationTesting續(xù)進(jìn)展。另外，在“規(guī)劃力氣”領(lǐng)域內(nèi)，該方法也常被用來(lái)評(píng)估“該如何調(diào)整才能實(shí)現(xiàn)系統(tǒng)并發(fā)測(cè)試〔ConcurrencyTesting〕并發(fā)測(cè)試〔ConcurrencyTesting〕方法通過(guò)模擬用戶的并發(fā)訪問(wèn)，測(cè)試多用戶并發(fā)訪問(wèn)同一個(gè)應(yīng)用、同一個(gè)模塊或者數(shù)據(jù)記錄時(shí)是否存在死鎖或者其他性能問(wèn)題。該方法具有以下特點(diǎn)：這種性能測(cè)試方法的主要目的是覺(jué)察系統(tǒng)中可能隱蔽的并發(fā)訪問(wèn)時(shí)的問(wèn)題。ConcurrencyTesting后，就常常會(huì)消滅各種莫名其妙的問(wèn)題。解決這類問(wèn)題的方法是進(jìn)展認(rèn)真的并發(fā)模擬測(cè)試。這種性能測(cè)試方法主要關(guān)注系統(tǒng)可能存在的并發(fā)問(wèn)題，例如系統(tǒng)中的內(nèi)存泄露、線程鎖和資源爭(zhēng)用方面的問(wèn)題。ConcurrencyTesting2-1出了并發(fā)測(cè)試主要關(guān)注的問(wèn)題。2-1并發(fā)測(cè)試主要關(guān)注的問(wèn)題問(wèn)題類別問(wèn)題類別問(wèn)題描述是否有內(nèi)存泄露〔C/C++〕內(nèi)存問(wèn)題是否有太多的臨時(shí)對(duì)象〔java〕是否有太多的超過(guò)設(shè)計(jì)生命周期的對(duì)象〔java〕是否有數(shù)據(jù)庫(kù)死鎖〔DeadLock〕數(shù)據(jù)庫(kù)問(wèn)題是否常常消滅長(zhǎng)事務(wù)〔LongTransaction〕線程/進(jìn)程問(wèn)題是否消滅線程/進(jìn)程同步失敗是否消滅資源爭(zhēng)用導(dǎo)致的死鎖其他問(wèn)題是否沒(méi)有正常處理特別〔例如超時(shí)等〕導(dǎo)致系統(tǒng)死鎖這種性能測(cè)試方法可以在開(kāi)發(fā)的各個(gè)階段使用支持。發(fā)負(fù)載的產(chǎn)生外，還需要一些其他工具進(jìn)展代碼級(jí)別的檢查和定位。Compuware公司的DevPartnerdj-technologieJProfileQuestJProbe以在這方面發(fā)揮作用。牢靠性測(cè)試〔ReliabilityTesting〕這里說(shuō)的“牢靠性測(cè)試”并不等同于“獲得軟件的牢靠性”，軟件的牢靠性是一個(gè)很大的命題，這里指的牢靠性測(cè)試是通過(guò)給系統(tǒng)加載確定的業(yè)務(wù)壓力〔例如：資源在70%~90%的使用率〕，讓?xiě)?yīng)用系統(tǒng)運(yùn)行一段時(shí)間、測(cè)試系統(tǒng)是否穩(wěn)定運(yùn)行。這里有三點(diǎn)需要留意：在使用該測(cè)試前需要目的系統(tǒng)的資源使用率已經(jīng)到達(dá)70%~90刻環(huán)境下運(yùn)行該應(yīng)用系統(tǒng)。90%。比方：該J2EE系統(tǒng)中設(shè)置的JDBC數(shù)據(jù)庫(kù)連接池定義為30，那么加載業(yè)務(wù)壓力使連接到達(dá)27。要求MTBF〔平均無(wú)故障時(shí)間〕到達(dá)10000小時(shí)、那么我們可以認(rèn)定該系統(tǒng)的運(yùn)行時(shí)間至少需要到達(dá)三年重啟動(dòng)一次。超過(guò)這個(gè)數(shù)字我們就可以認(rèn)為“不行靠”J2EE90%~1003可以認(rèn)定該MTBF該方法具有以下特點(diǎn)：這種性能測(cè)試方法的主要目的是驗(yàn)證系統(tǒng)是否支持長(zhǎng)期穩(wěn)定的運(yùn)行。ReliabilityTesting方法的目的是驗(yàn)證系統(tǒng)是否能夠支持長(zhǎng)期穩(wěn)定的運(yùn)行，其原理在行的條件。這種性能測(cè)試方法需要在壓力下持續(xù)一段時(shí)間的運(yùn)行。2～3測(cè)試過(guò)程中需要關(guān)注系統(tǒng)的運(yùn)行狀況。在運(yùn)行過(guò)程中，一般需要關(guān)注系統(tǒng)的內(nèi)存使用狀況，系統(tǒng)的其他資源使用有無(wú)明顯的變失效恢復(fù)測(cè)試〔FailoverTesting〕該方法是針對(duì)有HACMP等冗余備份和EdgeServerforLBJ2EE假設(shè)這種狀況發(fā)生，用戶將受到多大程度的影響。該方法有以下特點(diǎn)：這種性能測(cè)試方法的主要目的是驗(yàn)證在局部故障狀況下，系統(tǒng)能否連續(xù)使用。有一臺(tái)或幾臺(tái)效勞器消滅問(wèn)題，應(yīng)用系統(tǒng)照舊能夠正常執(zhí)行業(yè)務(wù)。FailoverTesting方法可以在測(cè)試中模擬一臺(tái)或幾臺(tái)設(shè)備故障，驗(yàn)證預(yù)期的恢復(fù)技術(shù)是否能夠發(fā)揮作用。這種性能測(cè)試方法還需要指出，當(dāng)問(wèn)題發(fā)生的時(shí)候“能支持多少用戶訪問(wèn)”當(dāng)一臺(tái)或多臺(tái)效勞器消滅問(wèn)題后，系統(tǒng)確定會(huì)受到性甚至是功能上的局部損失。因此，些必要措施？”這種問(wèn)題的明確答案。測(cè)試。的系統(tǒng)。三、性能測(cè)試分析方法前一章著重介紹了目前常用的性能測(cè)試方法，本章主要簡(jiǎn)潔介紹一下常用的各種性能測(cè)試分析方法。1、內(nèi)存分析方法內(nèi)存分析方法主要是用于推斷系統(tǒng)有無(wú)遇到內(nèi)存瓶頸高系統(tǒng)性能表現(xiàn)。主要計(jì)數(shù)器包括MemoryPhysicalDisk內(nèi)存分析的主要步驟和方法如下：首先查看MemoryAvailableMbytes該值是用于描述系統(tǒng)可用內(nèi)存的直接指標(biāo)，在對(duì)系統(tǒng)進(jìn)展操作系統(tǒng)級(jí)別的內(nèi)存分析時(shí)，存可用。假設(shè)該指標(biāo)的數(shù)據(jù)比較小，系統(tǒng)可能消滅了內(nèi)存方面的問(wèn)題，此時(shí)需要進(jìn)一步分析。留意s/sec、sRead/secFaults/sec操作系統(tǒng)常常會(huì)使用磁盤交換的方式來(lái)提高系統(tǒng)可用的內(nèi)存量或是提高內(nèi)存的使用效率。這三個(gè)指標(biāo)直接反映了操作系統(tǒng)進(jìn)展磁盤交換的頻度。假設(shè)s/sec表示內(nèi)存有問(wèn)題，而可能是運(yùn)行使用內(nèi)存映射文件的程序所致。Faults/sec說(shuō)明白每秒發(fā)生頁(yè)面失效的次數(shù)，頁(yè)面失效次數(shù)越多，說(shuō)明操作系統(tǒng)向內(nèi)存中讀取的次數(shù)越多。此時(shí)還需要查看sRead/sec計(jì)數(shù)器，該計(jì)數(shù)器閥值為5，假設(shè)超過(guò)5，則可以判定存在內(nèi)存方面的問(wèn)題。依據(jù)PhysicalDiskPhysicalDisksRead/sec%DiskTimeAverageDiskQueueLengthsRead/sec%DiskTimeAverageDiskQueueLength則可能有磁盤瓶頸。但是假設(shè)AverageDiskQueueLengthsRead/sec于內(nèi)存缺乏。(備注：內(nèi)存分析方法用到的計(jì)數(shù)器指標(biāo)主要有：MemoryAvailableMbytes、Memorys/secsRead/sec和Faults/secPhysicalDisk%DiskTimeAverageDiskQueueLength)2、處理器分析方法處理器(CPU)也可能是系統(tǒng)的瓶頸，對(duì)處理器進(jìn)展性能分析的步驟如下：首先查看System%TotalProcessorTimeCPU假設(shè)該值的數(shù)值持續(xù)超過(guò)90%，則說(shuō)明整個(gè)系統(tǒng)面臨這處理器方面的瓶頸，需要增加處理器來(lái)提高性能。留意：由于操作系統(tǒng)本身的特性，在某些多CPU系統(tǒng)中，該數(shù)據(jù)本身并不大，但此時(shí)CPU其次查看每個(gè)CPU的Processor%ProcessorTimeProcessor%UserTimeProcessor%PrivilegedTime。