性能測(cè)試、分析、優(yōu)化的方法論

前言理論來(lái)源于實(shí)踐又服務(wù)于實(shí)踐，在筆者多年的IT經(jīng)驗(yàn)中，性能問(wèn)題一直是相對(duì)復(fù)雜的高階問(wèn)題，從性能測(cè)試到分析再到優(yōu)化，考驗(yàn)的是工程師的綜合IT技能。一個(gè)系統(tǒng)整體的性能牽扯到方方面面，硬件配置、網(wǎng)絡(luò)配置、操作系統(tǒng)、中間件、應(yīng)用架構(gòu)、代碼質(zhì)量等等都會(huì)影響到系統(tǒng)的整體性能。初入性能領(lǐng)域的工程師可能感覺(jué)到無(wú)從下手。本文主要介紹相關(guān)性能測(cè)試、分析、優(yōu)化的方法論。希望通過(guò)方法論的學(xué)習(xí)，可以幫助工程師在復(fù)雜紛亂的環(huán)境下明確性能目標(biāo)，制定合理可行的性能測(cè)試計(jì)劃，有針對(duì)性的進(jìn)行性能分析，發(fā)現(xiàn)系統(tǒng)真正的性能瓶頸，并最終能夠進(jìn)行有效的性能優(yōu)化。1相關(guān)概念介紹1.1軟件測(cè)試分類軟件測(cè)試按照測(cè)試階段、是否運(yùn)行程序、是否查看源代碼以及其他方式，可以用下圖所示來(lái)描述軟件測(cè)試的各種分類。

1.2性能測(cè)試分類系統(tǒng)的性能是一個(gè)很大的概念，覆蓋面非常廣泛，對(duì)一個(gè)軟件系統(tǒng)而言，包括：執(zhí)行效率、資源占用、系統(tǒng)穩(wěn)定性、安全性、兼容性、可靠性、可擴(kuò)展性等。性能測(cè)試是為描述測(cè)試對(duì)象與性能相關(guān)的特征并對(duì)其進(jìn)行評(píng)價(jià)，而實(shí)施和執(zhí)行的一類測(cè)試。它主要通過(guò)自動(dòng)化的測(cè)試工具模擬多種正常、峰值以及異常負(fù)載條件來(lái)對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測(cè)試。通常大家把性能測(cè)試、負(fù)載測(cè)試、壓力測(cè)試統(tǒng)稱為性能測(cè)試。1．基準(zhǔn)測(cè)試:在給系統(tǒng)施加較低壓力時(shí)，查看系統(tǒng)的運(yùn)行狀況并記錄相關(guān)數(shù)作為基礎(chǔ)。2．負(fù)載測(cè)試:是指對(duì)系統(tǒng)不斷地增加壓力或增加一定壓力下的持續(xù)時(shí)間，直到系統(tǒng)的某項(xiàng)或多項(xiàng)性能指標(biāo)達(dá)到安全臨界值，例如某種資源已經(jīng)達(dá)到飽和狀態(tài)等。3．壓力測(cè)試:壓力測(cè)試是評(píng)估系統(tǒng)處于或超過(guò)預(yù)期負(fù)載時(shí)的運(yùn)行情況，關(guān)注點(diǎn)在于系統(tǒng)在峰值負(fù)載或超出最大載荷情況下的處理能力。4．穩(wěn)定性測(cè)試:在給系統(tǒng)加載一定業(yè)務(wù)壓力的情況下，使系統(tǒng)運(yùn)行一段時(shí)間，以此檢測(cè)系統(tǒng)是否穩(wěn)定。5．并發(fā)測(cè)試:測(cè)試多個(gè)用戶同時(shí)訪間同一個(gè)應(yīng)用、同一個(gè)模塊或者數(shù)據(jù)記錄時(shí)是否存在死鎖或者其他性能問(wèn)題。1.3不同視角下的軟件性能用戶視角的軟件性能從用戶的角度來(lái)說(shuō)，軟件性能就是用戶操作軟件的響應(yīng)時(shí)間;用戶所體會(huì)到的“響應(yīng)時(shí)間”既有客觀的成分，也有主觀的成分。例如，用戶執(zhí)行了某個(gè)操作，該操作返回大量數(shù)據(jù)，從客觀的角度來(lái)說(shuō)，事務(wù)的結(jié)束應(yīng)該是系統(tǒng)返回所有的數(shù)據(jù)響應(yīng)時(shí)間應(yīng)該是從用戶操作開(kāi)始到所有數(shù)據(jù)返回完成的整個(gè)耗時(shí);但從用戶的主觀感知來(lái)說(shuō)，如果采用一種優(yōu)化的數(shù)據(jù)呈現(xiàn)策略，當(dāng)少部分?jǐn)?shù)據(jù)返回之后就立刻將數(shù)據(jù)呈現(xiàn)在用戶面前，則用戶感受到的響應(yīng)時(shí)間就會(huì)遠(yuǎn)遠(yuǎn)小于實(shí)際的事務(wù)響應(yīng)時(shí)間。對(duì)于典型的交互系統(tǒng)，2s之內(nèi)的響應(yīng)時(shí)間通常是被用戶所接受的;如果響應(yīng)時(shí)間為5s時(shí)，用戶的滿意程度將會(huì)受到一定的影響;當(dāng)交易響應(yīng)時(shí)間為10s時(shí)，那么大多數(shù)用戶將會(huì)不耐煩地關(guān)閉交易頁(yè)面，顯然這是非常糟糕的用戶體驗(yàn)。管理員視角的軟件性能管理員視角有時(shí)候也就是運(yùn)維人員的視角。對(duì)于運(yùn)維人員來(lái)說(shuō)，響應(yīng)時(shí)間當(dāng)然也很重要，運(yùn)維方關(guān)注更多的是系統(tǒng)運(yùn)行是否平穩(wěn)(響應(yīng)時(shí)間或者交易吞吐量是否有劇烈波動(dòng))，CPU、內(nèi)存、存儲(chǔ)等關(guān)鍵資源是否充足。另外，對(duì)于銀行這樣擁有海量用戶和較高交易吞吐量的企業(yè)來(lái)說(shuō)，系統(tǒng)是否具有較好的可擴(kuò)展性是很關(guān)鍵的(這決定了是否能夠通過(guò)資源調(diào)配和擴(kuò)充平穩(wěn)度過(guò)業(yè)務(wù)高峰)，包括：1．系統(tǒng)的響應(yīng)時(shí)間2．系統(tǒng)狀態(tài)的相關(guān)信息，如CPU、內(nèi)存、應(yīng)用服務(wù)器狀態(tài)、JVM可用內(nèi)存、數(shù)據(jù)庫(kù)的狀態(tài)等3．系統(tǒng)的可擴(kuò)展性，即處理并發(fā)的能力4．系統(tǒng)可能的最大容量和可能的性能瓶頸，通過(guò)更換哪些設(shè)備或是進(jìn)行哪些擴(kuò)展能夠提高系統(tǒng)的性能。5．長(zhǎng)時(shí)間運(yùn)行是否足夠穩(wěn)定，是否能夠不間斷地提供業(yè)務(wù)服務(wù)等。開(kāi)發(fā)視角的軟件性能開(kāi)發(fā)人員對(duì)性能的關(guān)注點(diǎn)更多的是系統(tǒng)投產(chǎn)上線后，響應(yīng)時(shí)間是否達(dá)到了用戶需求說(shuō)明書中的相關(guān)要求。此外，開(kāi)發(fā)人員更加關(guān)注編寫代碼的運(yùn)行效率、數(shù)據(jù)庫(kù)訪問(wèn)是否按照設(shè)想的訪問(wèn)路徑以及索引設(shè)置是否合理等，包括用戶和管理員關(guān)心的軟件性能。如何通過(guò)調(diào)整設(shè)計(jì)和代碼實(shí)現(xiàn)，或是如何通過(guò)調(diào)整系統(tǒng)設(shè)置等方法提高軟件的性能表現(xiàn)。如何發(fā)現(xiàn)并解決軟件設(shè)計(jì)和開(kāi)發(fā)過(guò)程中產(chǎn)生的由于多用戶訪問(wèn)引發(fā)的軟件障，也就是通常所說(shuō)的“性能瓶頸”和系統(tǒng)中存在的在大量用戶訪問(wèn)時(shí)表現(xiàn)出來(lái)的缺陷。1.4性能衡量指標(biāo)響應(yīng)時(shí)間請(qǐng)求響應(yīng)時(shí)間指的是客戶端發(fā)出請(qǐng)求到得到響應(yīng)的整個(gè)過(guò)程的時(shí)間。這個(gè)過(guò)程是從客戶端發(fā)起一個(gè)請(qǐng)求開(kāi)始計(jì)時(shí)，到客戶端接收到從服務(wù)器端返回的響應(yīng)結(jié)果為止計(jì)時(shí)結(jié)束。在某些工具中，請(qǐng)求響應(yīng)時(shí)間通常會(huì)被稱為TTLB，即TimetoLastByte，意思是從發(fā)起一個(gè)請(qǐng)求開(kāi)始，到客戶端收到最后一個(gè)字節(jié)的響應(yīng)所耗費(fèi)的時(shí)間。請(qǐng)求響應(yīng)時(shí)間的單位一般為“秒（s）”或者“毫秒（ms）”。請(qǐng)求響應(yīng)時(shí)間的分解如下圖所示：從圖中可以看出，請(qǐng)求響應(yīng)時(shí)間為“網(wǎng)絡(luò)響應(yīng)時(shí)間”和“應(yīng)用程序與系統(tǒng)響應(yīng)時(shí)間”之和，具體由七個(gè)部分組成，即（N1+N2+N3+N4）+（A1+A2+A3）。并發(fā)用戶數(shù)并發(fā)用戶數(shù)也經(jīng)常被用來(lái)作為衡量系統(tǒng)并發(fā)處理能力的指標(biāo)，并發(fā)用戶數(shù)是指系統(tǒng)可以同時(shí)承載的正常使用系統(tǒng)功能的用戶數(shù)量。這個(gè)指標(biāo)也經(jīng)常被當(dāng)作衡量系統(tǒng)處理能力的重要指標(biāo)。實(shí)際上，籠統(tǒng)地將并發(fā)用戶數(shù)的大小作為衡量系統(tǒng)并發(fā)處理能力的指標(biāo)并不是十分科學(xué)的，因?yàn)椴l(fā)用戶又可以細(xì)分為在線用戶數(shù)和嚴(yán)格的并發(fā)用戶。在線用戶是指在同一時(shí)刻處于登錄狀態(tài)的用戶，在線用戶數(shù)僅僅表明有多少用戶處于登錄狀態(tài)，并不能說(shuō)明這些用戶正在進(jìn)行操作，在某些情況下，系統(tǒng)在線用戶數(shù)可能比較高，但是每秒處理交易數(shù)量有可能并不高。嚴(yán)格的并發(fā)用戶是指在同一時(shí)刻執(zhí)行統(tǒng)一操作的活躍用戶。較少的嚴(yán)格并發(fā)明戶數(shù)可能就會(huì)給系統(tǒng)造成較大的壓力，實(shí)際上絕大多數(shù)未經(jīng)過(guò)性能測(cè)試和未做調(diào)優(yōu)的應(yīng)用系統(tǒng)，5～10個(gè)嚴(yán)格并發(fā)用戶就能或多或少地給系統(tǒng)造成性能間題。系統(tǒng)用戶數(shù)是指系統(tǒng)注冊(cè)的總用戶數(shù)。三者之間的關(guān)系:系統(tǒng)用戶數(shù)≥在線用戶數(shù)≥嚴(yán)格的并發(fā)用戶數(shù)。吞吐量單位時(shí)間內(nèi)處理的客戶端請(qǐng)求數(shù)量，直接體現(xiàn)軟件系統(tǒng)的性能承載能力。通常情況下，吞吐率可以用“請(qǐng)求數(shù)/秒”“頁(yè)面數(shù)/秒”來(lái)衡量。從網(wǎng)絡(luò)角度，吞吐量一般以“字節(jié)/秒”來(lái)衡量。TPS（TransactionPerSecond）是指每秒鐘系統(tǒng)能夠處理的交易或者事務(wù)的數(shù)量，用來(lái)衡量系統(tǒng)業(yè)務(wù)處理能力的重要指標(biāo)。對(duì)于一些日交易量比較大的系統(tǒng)，通常在測(cè)試報(bào)告中用每秒完成多少萬(wàn)筆或8/12/24小時(shí)完成多少萬(wàn)筆交易來(lái)描述系統(tǒng)的業(yè)務(wù)處理能力，這樣可以感覺(jué)更直觀。大體來(lái)說(shuō)，對(duì)于交互式應(yīng)用，用戶直接的體驗(yàn)是響應(yīng)時(shí)間，通過(guò)并發(fā)用戶數(shù)和響應(yīng)時(shí)間可以確定系統(tǒng)的性能規(guī)劃，但對(duì)于非交互式應(yīng)用，用“吞吐量”來(lái)描述我們對(duì)系統(tǒng)性能的期望會(huì)更加合理。對(duì)于交互式應(yīng)用來(lái)說(shuō)，吞吐量指標(biāo)反映的是服務(wù)器承受的壓力。在容量規(guī)劃的測(cè)試中，吞吐量是一個(gè)重點(diǎn)關(guān)注的指標(biāo)，因?yàn)樗軌蛘f(shuō)明系統(tǒng)級(jí)別的負(fù)載能力。另外，在性能調(diào)優(yōu)的過(guò)程中，吞吐量指標(biāo)也有重要的價(jià)值。如在web系統(tǒng)的性能測(cè)試過(guò)程中，吞吐量以請(qǐng)求數(shù)/秒來(lái)體現(xiàn)，吞吐量指標(biāo)可以在兩個(gè)方面發(fā)揮左右：用于協(xié)助設(shè)計(jì)性能測(cè)試場(chǎng)景，以及衡量性能測(cè)試場(chǎng)景是否達(dá)到了預(yù)期的實(shí)際目標(biāo)。用于協(xié)助分析性能瓶頸，吞吐量的限制是性能瓶頸的一種重要表現(xiàn)形式，因此，由針對(duì)性的對(duì)吞吐量進(jìn)行測(cè)試，可以盡快定位到性能瓶頸所在位置。比如說(shuō)，RBI（rapidbottleneckidentify）方法就主要通過(guò)吞吐量測(cè)試發(fā)現(xiàn)性能瓶頸。

2性能測(cè)試方法論2.1性能測(cè)試方法2.1.1RBI（rapidbottleneckidentify）方法RBI（rapidbottleneckidentify）方法是Empirix公司提出的一種用于快速識(shí)別系統(tǒng)性能瓶頸的方法。該方法基于以下一些事實(shí)：1．發(fā)現(xiàn)的80%系統(tǒng)的性能瓶頸都由吞吐量制約。2．并發(fā)用戶數(shù)和吞吐量瓶頸之間存在一定的關(guān)聯(lián)。3．采用吞吐量測(cè)試可以更快速的定位問(wèn)題。RBI方法首先訪問(wèn)服務(wù)器上的小頁(yè)面和簡(jiǎn)單應(yīng)用，從應(yīng)用服務(wù)器，網(wǎng)絡(luò)等基礎(chǔ)的層面上了解系統(tǒng)吞吐量表現(xiàn)。其次選擇不同的場(chǎng)景，設(shè)定不同的并發(fā)用戶數(shù)，使其吞吐量保持基本一致的增長(zhǎng)趨勢(shì)，通過(guò)不斷增加并發(fā)用戶數(shù)和吞吐量，觀察系統(tǒng)的性能表現(xiàn)。在確定具體的性能瓶頸時(shí)，RBI將性能瓶頸的定位按照一種“自下而上”的分析方式進(jìn)行分析，首先確定是由并發(fā)還是由吞吐量引發(fā)的性能表現(xiàn)限制，然后從網(wǎng)絡(luò)，數(shù)據(jù)庫(kù)，應(yīng)用服務(wù)器和代碼本身4個(gè)環(huán)節(jié)確定系統(tǒng)性能具體的瓶頸。RBI方法在性能瓶頸的定位過(guò)程中能發(fā)揮良好的作用，其對(duì)性能分析和瓶頸定位有很強(qiáng)的借鑒意義。2.1.2性能下降曲線分析法性能下降曲線實(shí)際上描述的是性能隨客戶數(shù)量增加而出現(xiàn)下降趨勢(shì)的曲線。這里的性能可以是響應(yīng)時(shí)間，也可以是吞吐量。性能曲線大體分成以下幾個(gè)部分:1．性能平坦區(qū)在不進(jìn)行性能調(diào)優(yōu)的情況下所能期望達(dá)到的最佳性能。這個(gè)區(qū)域可以被用來(lái)做性能基線或者benchmark。2．壓力區(qū)應(yīng)用出現(xiàn)性能輕微下降的地方。典型的，最大的建議用戶負(fù)載是壓力區(qū)域的開(kāi)始。3．性能拐點(diǎn)性能開(kāi)始急劇下降的點(diǎn)。這幾個(gè)區(qū)域?qū)嶋H上明確標(biāo)識(shí)了系統(tǒng)性能最優(yōu)秀的區(qū)間。系統(tǒng)性能開(kāi)始變壞的區(qū)間，以及性能出現(xiàn)急劇下降的點(diǎn)。對(duì)于性能測(cè)試來(lái)說(shuō)，找到這些區(qū)間和拐點(diǎn)，就可以找到性能瓶頸產(chǎn)生的地方。2.2壓力測(cè)試工具針對(duì)不同場(chǎng)景，一般有不同層面的性能測(cè)試工具。系統(tǒng)層面，比如Linux環(huán)境下，針對(duì)不同的系統(tǒng)組件存在不同的系統(tǒng)壓測(cè)工具。最常見(jiàn)的是系統(tǒng)的sysbench組件包所包含的工具。下圖是性能領(lǐng)域領(lǐng)域?qū)＜褺rendanGregg的提供linuxsystembenchtools圖，供參考。命令的詳細(xì)用法可以通過(guò)man查閱。應(yīng)用層面，目前web應(yīng)用整體一般采用loadrunner或者jmeter進(jìn)行壓力測(cè)試。（loadrunner可以通過(guò)錄制操作自動(dòng)生成測(cè)試腳本。Jmeter可以使用badboy錄制操作步驟，生成jmeter運(yùn)行腳本）。對(duì)于沒(méi)有web的一些后端應(yīng)用，特別是基于webservice的微服務(wù)，一般采用soapui或者postman進(jìn)行壓力測(cè)試（soapui和postman的另一個(gè)強(qiáng)大功能是可以根據(jù)測(cè)試結(jié)果自動(dòng)創(chuàng)建樁代碼服務(wù)器，這在存在大量關(guān)聯(lián)應(yīng)用的環(huán)境下，尤為有用）。2.3性能觀測(cè)工具在Linux環(huán)境下，存在不同層面的性能觀測(cè)工具，用于分析不同層面的系統(tǒng)性能。比如常見(jiàn)的nmon、top命令用于系統(tǒng)全局性的觀測(cè)，sar用于統(tǒng)計(jì)性的觀測(cè)。下面是BrendanGregg提供的圖，供參考。中間件、數(shù)據(jù)庫(kù)層面也有類似工具

如WAS（IBMWebSphereApplicationServer），就有自帶的TPV（TivoliPerformanceViewer）WAS外部監(jiān)控工具PTT（WebSphereApplicationServerPerformanceTuningToolkit）這些監(jiān)控工具會(huì)提供詳細(xì)的KPI監(jiān)控?cái)?shù)據(jù)，通過(guò)分析相關(guān)KPI，我們可以確定性能瓶頸或者找到性能瓶頸的可疑點(diǎn)。2.4性能分析方法2.4.1AdHoc核對(duì)清單法當(dāng)需要檢查和調(diào)試系統(tǒng)時(shí)，技術(shù)支持人員通常會(huì)花一點(diǎn)時(shí)間一步步地過(guò)一遍核對(duì)清單。一個(gè)典型的場(chǎng)景，在產(chǎn)品環(huán)境部署新的服務(wù)器或應(yīng)用時(shí)，技術(shù)支持人員會(huì)花半天的時(shí)間來(lái)檢查一遍系統(tǒng)在真實(shí)壓力下的常見(jiàn)問(wèn)題。該類核對(duì)清單就是AdHoc（基于對(duì)該系統(tǒng)類型的經(jīng)驗(yàn)和之前所遇到的問(wèn)題所羅列的清單）。舉個(gè)例子，如下是核對(duì)清單中的一項(xiàng):運(yùn)行iostat-x1檢查await列。如果該列在負(fù)載下持續(xù)超過(guò)10(ms)，那么說(shuō)明磁盤太慢或是磁盤過(guò)載。一份核對(duì)清單會(huì)包含很多這樣的檢查項(xiàng)目。這類清單能在最短的時(shí)間內(nèi)提供最大的價(jià)值，一般需要頻繁更新以保證反映當(dāng)前狀態(tài)。這類清單處理的多是修復(fù)方法容易記錄的問(wèn)題，例如設(shè)置可調(diào)參數(shù)，而不是針對(duì)源代碼或環(huán)境做定制的修復(fù)。AdHoc核對(duì)清單能有效保證所有人都知道如何檢查最糟糕的問(wèn)題，能覆蓋到所有顯而易見(jiàn)的問(wèn)題。核對(duì)清單必須寫得清楚而規(guī)范，詳細(xì)說(shuō)明如何辨別每一個(gè)問(wèn)題和如何做修復(fù)。舉例：BrendanGregg提供的60秒針對(duì)liunx做基礎(chǔ)性能判斷的命令列表，如下：再比如，在一個(gè)典型的基于WAS的web應(yīng)用場(chǎng)景下，下圖即可認(rèn)為是它的AdHoc核對(duì)清單。2.4.2USE方法(utilization、saturation、errors)該方法的核心是對(duì)于所有的資源，查看它的使用率、飽和度和錯(cuò)誤。術(shù)語(yǔ)說(shuō)明：1．資源:所有服務(wù)器物理元器件（CPU、總線…），某些軟件資源也能算在內(nèi)。2．使用率:在規(guī)定的時(shí)間間隔內(nèi)，資源用于服務(wù)工作的時(shí)間百分比。雖然資源繁忙，但是資源還有能力接受更多的工作，不能接受更多工作的程度被視為飽和度。3．飽和度:資源不能再服務(wù)更多額外工作的程度，通常有等待隊(duì)列。4．錯(cuò)誤:錯(cuò)誤事件的個(gè)數(shù)。一旦資源的容量達(dá)到100％的使用率，就無(wú)法接受更多的工作，資源或者會(huì)把工作進(jìn)行排隊(duì)(飽和)，或者會(huì)返回錯(cuò)誤。USE方法會(huì)將分析引導(dǎo)到一定數(shù)量的關(guān)鍵指標(biāo)上，這樣可以盡快地核實(shí)所有的系統(tǒng)資源。實(shí)操過(guò)程如下：這個(gè)方法辨別出的很可能是系統(tǒng)瓶頸問(wèn)題。不過(guò)，一個(gè)系統(tǒng)可能不只面臨一個(gè)性能間題，因此你可能一開(kāi)始就能找到問(wèn)題，但所找到的回題并非你關(guān)心的那個(gè)。在根據(jù)需要返回USE方法遍歷其他資源之前，每個(gè)發(fā)現(xiàn)可以用更多的方法進(jìn)行調(diào)查。USE方法的第一步是要建一張資源列表，要盡可能完整。下面是一張服務(wù)器通常的資源列表范例：1．CPU:插槽、核、硬件線程(虛擬CPU)2．內(nèi)存:DRAM3．網(wǎng)絡(luò)接口:以太網(wǎng)端口4．存儲(chǔ)設(shè)備:磁盤5．控制器:存儲(chǔ)、網(wǎng)絡(luò)6．互聯(lián):CPU、內(nèi)存、IO一旦你掌握了資源的列表，就可以采集這三類指標(biāo):使用率、飽和度，以及錯(cuò)誤。比如:1．CPU使用率（vmstat1）2．CPU飽和度（即運(yùn)行隊(duì)列長(zhǎng)度vmstat1）3．內(nèi)存使用率（free-m）4．內(nèi)存飽和度（匿名換頁(yè)或者線程換出再或者OOM）5．網(wǎng)絡(luò)接口使用率（sar–nDEV1）6．存儲(chǔ)使用率（設(shè)備繁忙百分比iostat–d–x1）7．存儲(chǔ)飽和度（等待隊(duì)列長(zhǎng)度iostat–d–x1）8．存儲(chǔ)設(shè)備IO（dmesgsmartctl）數(shù)據(jù)采集后，根據(jù)如下的建議找到瓶頸并進(jìn)行深入分析：使用率:100%的使用率通常是瓶頸的信號(hào)(檢查飽和度并確認(rèn)其影響)。使用率超過(guò)60％可能會(huì)是問(wèn)題，基于以下理由:時(shí)間間隔的均值，可能掩蓋了100%使用率的短期爆發(fā)，另外，一些資源，諸如硬盤(不是CPU)，通常在操作期間是不能被中斷的，即使做的是優(yōu)先級(jí)較高的工作。隨著使用率的上升，排隊(duì)延時(shí)會(huì)變得更頻繁和明顯。飽和度:任何程度的飽和都是問(wèn)題(非零)。飽和程度可以用排隊(duì)長(zhǎng)度或者排隊(duì)所花的時(shí)間來(lái)度量。錯(cuò)誤:錯(cuò)誤都是值得研究的，尤其是隨著錯(cuò)誤增加性能會(huì)變差的那些錯(cuò)誤。2.4.3延時(shí)分析法延時(shí)分析檢查完成一項(xiàng)操作所用的時(shí)間，然后把時(shí)間再分成小的時(shí)間段，接著對(duì)有著最大延時(shí)的時(shí)間段做再次的劃分，最后定為并量化問(wèn)題的根本原因。一般情況下，延時(shí)分析需要深入到軟件棧中的各層去尋找延時(shí)問(wèn)題的原因。比如說(shuō)常見(jiàn)的web應(yīng)用，可以如下圖所示，先粗略的劃分各組件消耗時(shí)間。再深入到各組件內(nèi)部詳細(xì)分析延時(shí)。2.5性能分析遵循的常見(jiàn)原則2.5.12/5/8原則所謂響應(yīng)時(shí)間的“2-5-8原則”，簡(jiǎn)單地說(shuō):當(dāng)用戶能夠在2s以內(nèi)得到響應(yīng)時(shí)，會(huì)感覺(jué)系統(tǒng)的響應(yīng)很快;當(dāng)用戶在2至5s得到響應(yīng)時(shí)，會(huì)感覺(jué)系統(tǒng)的響應(yīng)速度還可以;當(dāng)用戶在5至8s得到響應(yīng)時(shí)，會(huì)感覺(jué)系統(tǒng)的響應(yīng)速度很慢，但是還可以接受;而當(dāng)用戶在超過(guò)8s后仍然無(wú)法得到響應(yīng)時(shí)，會(huì)感覺(jué)系統(tǒng)糟透了，或者認(rèn)為系統(tǒng)已經(jīng)失去響應(yīng)，而選擇離開(kāi)這個(gè)Web站點(diǎn)，或者發(fā)起第二次請(qǐng)求。2.5.2二八原則二八定律也叫巴萊多定律，是19世紀(jì)末20世紀(jì)初意大利經(jīng)濟(jì)學(xué)家巴萊多發(fā)明的。該定律的主要內(nèi)容為:在任何一組東西中，最重要的只占其中一小部分，約20％;其余80％的盡管是多數(shù)，卻是次要的，因此又稱二八法則。用于減少風(fēng)險(xiǎn)、抓住重點(diǎn)進(jìn)行更多的測(cè)試:用戶80％的時(shí)間在使用軟件產(chǎn)品中20％的功能?！爸攸c(diǎn)測(cè)試”就是測(cè)試這20％的功能，而其他80％的功能屬于優(yōu)先級(jí)低的測(cè)試范圍，占20％的測(cè)試資源。實(shí)例:對(duì)測(cè)試強(qiáng)度估算基本概念:每個(gè)工作日80％的業(yè)務(wù)在20％的時(shí)間內(nèi)完成。例如每天工作8h，那么每天80％的業(yè)務(wù)在8×20％＝1.6h內(nèi)完成。二八原則其他含義80％的錯(cuò)誤是由20％的模塊引起的。站在用戶角度，并非研發(fā)實(shí)現(xiàn)的角度出發(fā)，正確地