java性能測(cè)試原則

1、引言計(jì)算機(jī)軟件作為人類智慧的結(jié)晶，幫助我們?cè)谶@個(gè)日新月異的社會(huì)中完成了大量工作。 我們的日常生活中已經(jīng)離不開(kāi)軟件，玲瑯滿目的軟件已經(jīng)滲透到了我們生活的各個(gè)角落，令 我們目不暇接。我們都希望軟件變得更好，運(yùn)行處理的速度更快，在當(dāng)今硬件性能突飛猛進(jìn) 的變革中，軟件性能的提升也是一個(gè)永不落伍的話題。軟件性能測(cè)試的實(shí)質(zhì)，是從哲學(xué)的角 度看問(wèn)題，找出其內(nèi)在聯(lián)系，因果關(guān)系，形式內(nèi)容關(guān)系，重疊關(guān)系等等。假如這些關(guān)系我們 在分析過(guò)程中理清了，那么性能測(cè)試問(wèn)題就會(huì)變得迎刃而解。在軟件開(kāi)發(fā)過(guò)程中，性能測(cè)試往往在開(kāi)發(fā)前期容易被忽略。直到有一天問(wèn)題暴露后，開(kāi) 發(fā)人員被迫的直面這個(gè)問(wèn)題，大多數(shù)情況下，這是令開(kāi)發(fā)人員感覺(jué)

2、到非常痛苦事情。所以在 軟件開(kāi)發(fā)前期以及開(kāi)發(fā)過(guò)程中性能測(cè)試的考量是必要的，那么具備相應(yīng)理論知識(shí)和實(shí)踐方法 也是一個(gè)優(yōu)秀工程師所應(yīng)當(dāng)具備的素養(yǎng)，這里我們概括有四項(xiàng)原則，這些原則可以幫助開(kāi)發(fā) 人員豐富、充實(shí)測(cè)試?yán)碚?，系統(tǒng)的開(kāi)展性能測(cè)試工作，從而獲得更有價(jià)值的結(jié)果。實(shí)際項(xiàng)目中的性能測(cè)試才有意義第一個(gè)原則就是性能測(cè)試只有在實(shí)際項(xiàng)目中實(shí)施才是有意義的，這樣才使得測(cè)試工作具 有針對(duì)性，而且目標(biāo)會(huì)更加明確。這個(gè)原則中有三個(gè)類別的基準(zhǔn)可以指導(dǎo)開(kāi)發(fā)人員度量性能 測(cè)試的結(jié)果，但是每一種方法都有它的優(yōu)點(diǎn)和劣勢(shì)，我們將結(jié)合實(shí)際例子，來(lái)總結(jié)闡述。微觀基準(zhǔn)，可以理解為在某一個(gè)方法或某一個(gè)組件中進(jìn)行的單元性能測(cè)試。比如檢測(cè)

3、一 個(gè)線程同步和一個(gè)非線程同步的方法運(yùn)行時(shí)所需要的時(shí)間。或者對(duì)比創(chuàng)建一個(gè)單獨(dú)線程和使 用一個(gè)線程池的性能開(kāi)銷?；蛘邔?duì)比執(zhí)行一個(gè)算法中的某一個(gè)迭代過(guò)程所需要的時(shí)間。當(dāng)我 們遇到這些情況時(shí)，我們常常會(huì)選擇做一個(gè)方法層面的性能測(cè)試。這些情況的性能測(cè)試，都 可以嘗試使用微觀基準(zhǔn)的方法進(jìn)行性能測(cè)試。微觀基準(zhǔn)看似編寫起來(lái)簡(jiǎn)單快捷，但是編寫能 夠準(zhǔn)確反映性能問(wèn)題的代碼并非一件易事。接下來(lái)通過(guò)例子讓我們從代碼中發(fā)現(xiàn)一些問(wèn)題。 這是一個(gè)單線程的程序片段，通過(guò)計(jì)算50次循環(huán)迭代來(lái)檢測(cè)執(zhí)行方法所耗費(fèi)的時(shí)間體現(xiàn) 性能差異：public void doTest() double l;long then = System

4、.currentTimeMillis();intnLoops = 50;for (int i = 0; i nLoops; i+) l = compute(50);long now = System.currentTimeMillis();System.out.println(Elapsed time: + (now - then);private double compute(int n)if (n 0);if (n = 0) return 0d; if (n = 1)return 1d;double d = compute(n - 2) + compute(n - 1);if (Doubl

5、e.isInfinite(d)throw new ArithmeticException(Overflow);return d;執(zhí)行這段代碼我們會(huì)發(fā)現(xiàn)一個(gè)問(wèn)題，那就是執(zhí)行時(shí)間只有短短的幾秒。難道果真是程序性 能很高？答案并非如此，其實(shí)在整個(gè)執(zhí)行過(guò)程中compute計(jì)算方法并沒(méi)有調(diào)用而是被編譯 器自動(dòng)忽略了。那么解決這個(gè)問(wèn)題的辦法是將double類型的“換成volatile實(shí)例變量。這 樣能夠確保每一個(gè)計(jì)算后所得到的結(jié)果是可以被記錄下來(lái)，用volatile修飾的變量，線程 在每次使用變量的時(shí)候，都會(huì)讀取變量修改后的最后的值。要特別值得注意的是，當(dāng)考慮為多線程寫一個(gè)微基準(zhǔn)性能測(cè)試用例時(shí)，假如幾個(gè)線

6、程同 時(shí)執(zhí)行一小段業(yè)務(wù)邏輯代碼，這可能會(huì)引發(fā)潛在的線程同步所帶來(lái)的性能開(kāi)銷和瓶頸。此時(shí) 微觀微基準(zhǔn)測(cè)試的結(jié)果往往引導(dǎo)開(kāi)發(fā)人員為了保持同步進(jìn)行不斷的優(yōu)化，這樣會(huì)浪費(fèi)很多時(shí) 間，對(duì)于解決更緊迫的性能問(wèn)題，這樣做就顯得得不償失。我們?cè)僭囅脒@樣一個(gè)例子，微基準(zhǔn)測(cè)試兩個(gè)線程調(diào)用同步方法的情況，因?yàn)榛鶞?zhǔn)代碼很 小，那么測(cè)試用例大部分時(shí)間將消耗在同步過(guò)程中。即使微基準(zhǔn)測(cè)試在整體的同步過(guò)程中只 占50%，那么兩個(gè)線程嘗試執(zhí)行同步方法的幾率也是相當(dāng)高的?；鶞?zhǔn)運(yùn)行將會(huì)非常緩慢， 添加額外的線程會(huì)造成更大的性能問(wèn)題。基于微觀基準(zhǔn)的測(cè)試過(guò)程中，是不能含有額外的對(duì)性能產(chǎn)生影響的操作，我們知道執(zhí)行 compute(100

7、0)和compute(1)在性能上是有很大差異的，假如我們的目標(biāo)是對(duì)比兩個(gè)不 同實(shí)現(xiàn)方法之間的性能差異，那么就應(yīng)當(dāng)考慮一系列的輸入測(cè)試值作為前提，傳遞給測(cè)試目 標(biāo)，參數(shù)就需要多樣化。這里以我們的經(jīng)驗(yàn)解決的辦法就是使用隨機(jī)值：for (int i = 0; i nLoops; i+) l = compute(random.nextInt();現(xiàn)在，產(chǎn)生隨機(jī)數(shù)的時(shí)間也包含在了整個(gè)循環(huán)執(zhí)行過(guò)程中，因此測(cè)試結(jié)果中包含了隨機(jī) 數(shù)生成所需要的時(shí)間，這并不能客觀的體現(xiàn)compute方法真實(shí)的性能。所以在構(gòu)建微觀基 準(zhǔn)時(shí)，輸入的測(cè)試值必須是預(yù)先準(zhǔn)備好的，且不會(huì)對(duì)性能測(cè)試產(chǎn)生額外的影響。正確的做法 如下：pub

8、lic void doTest() double l;intnLoops = 10;Random random = new Random();int input = new intnLoops;for (int i = 0; i nLoops; i+) inputi = random.nextInt();long then = System.currentTimeMillis();for (int i = 0; i nLoops; i+) try l = compute(inputi); catch (IllegalArgumentExceptioniae) long now = System

9、.currentTimeMillis();System.out.println(Elapsed time: + (now - then);微觀基準(zhǔn)中輸入的測(cè)試值必須是符合業(yè)務(wù)邏輯的。所有的輸入的值并不一定會(huì)被代碼用到， 實(shí)際的業(yè)務(wù)可能對(duì)輸入的數(shù)據(jù)有特定的要求，不合理的輸入值可能導(dǎo)致代碼在執(zhí)行過(guò)程中就 拋出異常而中斷，從而使得我們難以判斷代碼執(zhí)行的效率。所以在準(zhǔn)備測(cè)試數(shù)據(jù)的時(shí)候應(yīng)當(dāng) 考慮到輸入數(shù)據(jù)的有效性，保證代碼執(zhí)行的完整性。比如下面的例子輸入的參數(shù)如果是大于 1476，執(zhí)行會(huì)立即中斷，從而影響了真實(shí)性能結(jié)果的產(chǎn)生。public double ImplSlow(int n) if (n 0);

10、if (n 1476) throw new ArithmeticException(Must be 1476);return verySlowImpl(n);通常情況下，對(duì)參與到實(shí)際業(yè)務(wù)計(jì)算的值提前檢測(cè)對(duì)提升性能是有幫助的，但是假如用戶大 多數(shù)輸入的值是合理的，那么提前檢查數(shù)據(jù)的有效性就顯得冗余了。所以編寫核心邏輯代碼 的時(shí)候，我們建議只針對(duì)一般情況做處理，保證執(zhí)行的效率的高效性。假設(shè)訪問(wèn)一個(gè) collection對(duì)象時(shí)，每一次能夠節(jié)省幾毫秒的話，那么在多次的訪問(wèn)情況下就會(huì)對(duì)性能的提 升產(chǎn)生重大的意義。public class Test1 private volatile double l;p

11、rivate intnLoops;private int input;private Test1(int n) nLoops = n;input = new intnLoops;Random random = new Random();for (int i = 0; i nLoops; i+) inputi = random.nextInt(50);public void doTest(booleanisWarmup) long then = System.currentTimeMillis();for (int i = 0; i nLoops; i+) try l = compute(inp

12、uti); catch (IllegalArgumentExceptioniae) if (!isWarmup) long now = System.currentTimeMillis();System.out.println(Elapsed time: + (now - then);private double compute(int n) if (n 0);if (n = 0)return 0d;if (n = 1)return 1d;double d = compute(n - 2) + compute(n - 1);if (Double.isInfinite(d)throw new A

13、rithmeticException(Overflow);return d;public static void main(String args) / TODO Auto-generated method stubTest1 test1 = new Test1(Integer.parseInt(10”););test1.doTest(true);test1.doTest(false);總得說(shuō)來(lái)，微觀基準(zhǔn)作用是有限的，在頻繁調(diào)用的方法中使用微觀基準(zhǔn)的度量方法會(huì)幫助 我們檢測(cè)代碼的性能，如果用在不會(huì)被頻繁調(diào)用的方法中是不合適的，應(yīng)當(dāng)考慮其它方法。宏觀基準(zhǔn)，當(dāng)我們測(cè)量應(yīng)用程序性能時(shí)，應(yīng)當(dāng)縱覽整個(gè)系

14、統(tǒng)，影響應(yīng)用程序性能的原因可能 是多方面的，不能片面的認(rèn)為性能瓶頸只會(huì)在程序本身上。通過(guò)下面這個(gè)例子我們將探討離 開(kāi)宏觀基準(zhǔn)的性能測(cè)試是不可能找到影響應(yīng)用程序性能真正的瓶頸。上圖數(shù)據(jù)來(lái)自客戶實(shí)體，觸發(fā)應(yīng)用程序的核心業(yè)務(wù)計(jì)算方法，該方法從數(shù)據(jù)庫(kù)加載數(shù)據(jù)，LDAP查陸 (2響應(yīng)客戶清求(500 RPS并傳導(dǎo)給核心業(yè)務(wù)中的計(jì)算方法，得到結(jié)果保存到數(shù)據(jù)庫(kù)，最終響應(yīng)客戶的請(qǐng)求。每個(gè)圖形 中的數(shù)字分別代表了這個(gè)模塊所能處理客戶請(qǐng)求的數(shù)量。核心業(yè)務(wù)模塊的優(yōu)化多數(shù)情況是受 限于業(yè)務(wù)的要求。假設(shè)我們優(yōu)化這些核心模塊，使其可以處理200 RPS時(shí)，我們發(fā)現(xiàn)加載數(shù)據(jù)的模塊依然只能處理100 RPS，也就是說(shuō)整個(gè)系統(tǒng)

15、的吞吐能力其實(shí)仍然為100 RPS， 最終對(duì)應(yīng)用程序整體的性能提升是沒(méi)有任何幫助的。從這個(gè)例子我們得知，我們花費(fèi)再多的 精力在核心業(yè)務(wù)上的優(yōu)化意義并不大，我們應(yīng)當(dāng)從整體運(yùn)行情況來(lái)看，發(fā)現(xiàn)真正影響性能的 瓶頸來(lái)解決問(wèn)題，這就是宏觀基準(zhǔn)原則的意義。折衷基準(zhǔn)，相比微觀基準(zhǔn)和宏觀基準(zhǔn)，一個(gè)單獨(dú)功能模塊的性能測(cè)試，或者一系列特定操作 的性能測(cè)試被稱為折衷基準(zhǔn)。它是介于微觀基準(zhǔn)和宏觀基準(zhǔn)之間的折衷方案?；谖⒂^基準(zhǔn) 測(cè)試的正確性是較難把握的，性能瓶頸的判斷絕不能僅僅依賴于此。如果我們要使用微觀基 準(zhǔn)作為性能的測(cè)量方法，那么不妨在此之前先嘗試基于宏觀基準(zhǔn)的測(cè)試。它可以幫助我們了 解系統(tǒng)以及代碼是如何工作的，

16、從而形成一個(gè)系統(tǒng)整體邏輯結(jié)構(gòu)圖。接下來(lái)可以考慮基于折 衷基準(zhǔn)的測(cè)試，來(lái)真正發(fā)現(xiàn)潛在的性能瓶頸。需要明確的是折衷基準(zhǔn)的測(cè)試方法并不是完整 應(yīng)用程序測(cè)試的替代方法，更多情況下我們認(rèn)為它更適用于一個(gè)功能模塊的自動(dòng)測(cè)試。批量，吞吐量和響應(yīng)時(shí)間的測(cè)量方法性能測(cè)試中的第二個(gè)重要的原則是引入多樣的測(cè)量方法來(lái)分析程序的性能。批量執(zhí)行所用時(shí)間的測(cè)量方法(耗時(shí)法)，這是種簡(jiǎn)單而快速有效的方法，通過(guò)測(cè)量完 成特定任務(wù)所消耗的時(shí)間來(lái)測(cè)量整體性能。但是需要特別注意，假如所測(cè)試的應(yīng)用程序中使 用緩存數(shù)據(jù)技術(shù)來(lái)為了獲得更好的性能表現(xiàn)時(shí)，多次循環(huán)使用該方法可能無(wú)法完全反應(yīng)性能 問(wèn)題。那么可以嘗試在初始狀態(tài)開(kāi)始時(shí)應(yīng)用耗時(shí)法做一

17、次性能的評(píng)估，然后當(dāng)緩存建立后， 再次嘗試此方法。吞吐量的測(cè)量方法，在一段時(shí)間內(nèi)考察完成任務(wù)的數(shù)量的能力，被稱為吞吐量測(cè)量方法。 在測(cè)試客戶服務(wù)器的應(yīng)用程序時(shí)，吞吐量的測(cè)量意味著客戶端發(fā)送請(qǐng)求到服務(wù)器是沒(méi)有任何 延遲的，當(dāng)客戶端接收到響應(yīng)后，應(yīng)當(dāng)立即發(fā)出新的請(qǐng)求，直到最終結(jié)束，統(tǒng)計(jì)客戶端完成 任務(wù)的總數(shù)。這種相對(duì)理想的測(cè)試方法通常稱之為“Zero-think-time”。可是通常情況下，客 戶端可能會(huì)有多個(gè)線程做同一件事情，吞吐量則意味著每秒鐘內(nèi)所有客戶端的操作數(shù)，而不 是測(cè)量的某一個(gè)時(shí)段內(nèi)的所有操作總數(shù)。這種測(cè)量經(jīng)常稱為每秒事務(wù)/(TPS)，每秒請(qǐng)求 (RPS)，或每秒操作數(shù)(OPS)。測(cè)試

18、所有基于客戶端和服務(wù)器端應(yīng)用程序都存在一種風(fēng)險(xiǎn)，客戶端不能以足夠快的速度發(fā)送 數(shù)據(jù)到服務(wù)器端，這種情況的發(fā)生可能是由于客戶端此時(shí)沒(méi)有足夠的CPU資源去運(yùn)行需 要數(shù)量的線程，或者客戶端必須耗用更長(zhǎng)的時(shí)間來(lái)處理當(dāng)前的請(qǐng)求。這種情況下，實(shí)際上測(cè) 量的是客戶端的性能，而非服務(wù)器的性能，與吞吐量測(cè)量方法是背道而馳的。其實(shí)這種風(fēng)險(xiǎn) 是由每個(gè)客戶端線程處理任務(wù)的數(shù)量和硬件配置決定的?！癦ero-think-time”在吞吐量測(cè)試中 可能經(jīng)常會(huì)遇見(jiàn)以上的情況，由于每個(gè)客戶端線程都需要處理大量的任務(wù)，因此吞吐量測(cè)試 通常被應(yīng)用于較少的客戶端線程程序。吞吐量測(cè)量方法也同樣適應(yīng)用于帶有緩存技術(shù)的應(yīng)用 程序，尤其是當(dāng)

19、測(cè)試的數(shù)據(jù)是一個(gè)并不固定的情況下。響應(yīng)時(shí)間的測(cè)量方法，響應(yīng)時(shí)間的測(cè)量方法是指客戶端發(fā)出一個(gè)請(qǐng)求后直到接收到服務(wù) 器的響應(yīng)返回后的時(shí)間消耗。響應(yīng)時(shí)間測(cè)量方法不同于吞吐量測(cè)量方法，在響應(yīng)時(shí)間測(cè)試過(guò) 程中，客戶端線程可能會(huì)在操作的過(guò)程中某一時(shí)刻休眠，這就引出“think- time ”這個(gè)關(guān)鍵詞， 當(dāng) “think- time ”被引入到測(cè)試過(guò)程中，也就是意味著待處理任務(wù)量是固定的，測(cè)量的是服務(wù) 器響應(yīng)請(qǐng)求的速率是怎樣的。大多數(shù)情況下，響應(yīng)時(shí)間的測(cè)量方法用來(lái)模擬用戶真實(shí)操作， 從而測(cè)量應(yīng)用程序的性能。多變性性能測(cè)試的第三個(gè)原則是理解測(cè)試結(jié)果如何隨時(shí)間改變，即使每一次測(cè)試使用同樣的數(shù) 據(jù)，可能獲得的結(jié)

20、果也是不同的。一些客觀因素，比如后臺(tái)運(yùn)行的進(jìn)程，網(wǎng)絡(luò)的負(fù)載情況， 這些都可能帶來(lái)測(cè)試結(jié)果的不同，所以在測(cè)試過(guò)程中存在著一些隨機(jī)性的因素。這就產(chǎn)生了 一個(gè)問(wèn)題：當(dāng)比較兩次運(yùn)行得到的測(cè)試結(jié)果時(shí)，它們之間的差異是由回歸測(cè)試產(chǎn)生的，還是 是隨機(jī)變化而導(dǎo)致的呢？我們不能簡(jiǎn)單的通過(guò)測(cè)量多次運(yùn)行回歸測(cè)試的平均結(jié)果來(lái)評(píng)判性能的差異。這時(shí)我們可 以使用統(tǒng)計(jì)分析的方法，假設(shè)兩種情況的平均值是一樣的，然后通過(guò)概率來(lái)判斷這樣的假設(shè) 是成立的。如果假設(shè)不成立，那么就說(shuō)明有很高的概率證明平均數(shù)存在差異。在回歸測(cè)試中原始代碼被視為基線，新增加的代碼稱為樣本。三次運(yùn)行基線和樣本，產(chǎn) 生時(shí)間如表1：次教菽*博本 TOC o 1

21、-5 h z 100.5g1 151.205，.箸軟件測(cè)試的自我修養(yǎng)平均1 0.75看起來(lái)樣本的平均值顯示有25%的提升，可事實(shí)證明樣本和基線有相同性能的概率是43%。 也就是說(shuō)57%的概率存在性能上的不同。43%是基于T檢驗(yàn)所得到的結(jié)果，T檢驗(yàn)主要 用于樣本含量較?。ɡ鏽30），總體標(biāo)準(zhǔn)差a未知的正態(tài)分布資料。t檢驗(yàn)是用t分布 理論來(lái)推論差異發(fā)生的概率，從而比較兩個(gè)平均數(shù)的差異是否顯著。它與z檢驗(yàn)、卡方檢 驗(yàn)并列。現(xiàn)在的T檢驗(yàn)結(jié)果告訴我們這樣一個(gè)信息:：57%概率顯示樣本和基線存在性能差 異，差異最大值是25%。也可以理解為性能差有57%的置信度向理想發(fā)現(xiàn)發(fā)展，結(jié)果有25% 的改善。在考量回歸測(cè)試的結(jié)果時(shí)，離開(kāi)了統(tǒng)計(jì)分析的方法，而只關(guān)注平均值來(lái)做出判斷，含糊 的理解這些數(shù)