【正文】 換在目錄里的任何打包文件為標(biāo)準(zhǔn)的JAR文件。* 每個(gè)打包文件轉(zhuǎn)換完成后被刪除。沒(méi)有打包文件時(shí)，該方法什么也不做。* @參數(shù)：包含打包文件的目錄libDir，解包時(shí)是否要顯示狀態(tài)printStatus */private void unpackArchives(File libDir, boolean printStatus){…}}4 即時(shí)通信系統(tǒng)的性能測(cè)試即時(shí)通信系統(tǒng)的性能測(cè)試屬于黑盒測(cè)試。性能測(cè)試方法是通過(guò)模擬生產(chǎn)運(yùn)行的業(yè)務(wù)壓力和所使用的場(chǎng)景組合，測(cè)試系統(tǒng)的性能是否滿足生產(chǎn)性能要求。這種方法主要的目的是驗(yàn)證系統(tǒng)是否達(dá)到其所規(guī)劃的能力，要求運(yùn)行環(huán)境必須是已經(jīng)確定的。因?yàn)檐浖到y(tǒng)的性能表現(xiàn)與非常多的因素相關(guān)，要求測(cè)試時(shí)的硬件設(shè)備、軟件環(huán)境、網(wǎng)絡(luò)條件和基礎(chǔ)數(shù)據(jù)等必須都已經(jīng)確定。 即時(shí)通信系統(tǒng)性能測(cè)試中使用的統(tǒng)計(jì)量目前在性能測(cè)試中使用的統(tǒng)計(jì)量包括：響應(yīng)時(shí)間（Response Time）、并發(fā)用戶數(shù)（Number of Concurrent Users）、吞吐量（Throughput）、性能計(jì)數(shù)器（Performance Counter）和思考時(shí)間（Think Time）等。 響應(yīng)時(shí)間響應(yīng)時(shí)間的定義為：對(duì)請(qǐng)求做出響應(yīng)所需要的時(shí)間。響應(yīng)時(shí)間是用戶視角的軟件性能的主要體現(xiàn)。具體來(lái)說(shuō)，當(dāng)用戶單擊一個(gè)按鈕、發(fā)出一條消息，從用戶單擊開(kāi)始到應(yīng)用系統(tǒng)把本次操作的結(jié)果以用戶能察覺(jué)的方式展示出來(lái)，這個(gè)過(guò)程所消耗的時(shí)間就是用戶對(duì)軟件性能的直觀印象。以本即時(shí)通信系統(tǒng)為例。 即時(shí)通信系統(tǒng)的響應(yīng) Response of IM System“呈現(xiàn)時(shí)間”和“系統(tǒng)響應(yīng)時(shí)間”兩個(gè)部分，其中“呈現(xiàn)時(shí)間”取決于數(shù)據(jù)在客戶端收到響應(yīng)數(shù)據(jù)后被處理并呈現(xiàn)頁(yè)面所消耗的時(shí)間；而“系統(tǒng)響應(yīng)時(shí)間”指即時(shí)通信系統(tǒng)從請(qǐng)求發(fā)出開(kāi)始到即時(shí)通信客戶端接收到數(shù)據(jù)所消耗的時(shí)間。響應(yīng)時(shí)間可以被進(jìn)一步分解。從圖中可以看到，消息的響應(yīng)時(shí)間可被分解為“網(wǎng)絡(luò)傳輸時(shí)間”（T1+T2+T3+T4）和“應(yīng)用延遲時(shí)間”（A1+A2+A3），而“應(yīng)用延遲時(shí)間”又可以分解為“數(shù)據(jù)庫(kù)延遲時(shí)間”（A2）和“即時(shí)通信服務(wù)器延遲時(shí)間”（A1+A3）。它們與響應(yīng)時(shí)間的關(guān)系可以如下表示：消息響應(yīng)時(shí)間=網(wǎng)絡(luò)傳輸時(shí)間＋即時(shí)通信服務(wù)器延遲時(shí)間＋數(shù)據(jù)庫(kù)延遲時(shí)間消息響應(yīng)時(shí)間=（T1＋T2＋T3＋T4）＋（A1＋A3）＋A2 即時(shí)通信的消息響應(yīng)時(shí)間分解 Resolving of Instance Message’s Response Time之所以要對(duì)響應(yīng)時(shí)間進(jìn)行這樣的分解，主要目的是為了能更好定位性能瓶頸。 并發(fā)用戶數(shù)（1）并發(fā)用戶數(shù)的概念如果性能測(cè)試時(shí)的目標(biāo)是驗(yàn)證當(dāng)前系統(tǒng)能否支持現(xiàn)有用戶的訪問(wèn)，最好的辦法就是獲得在同一時(shí)間段內(nèi)訪問(wèn)被測(cè)系統(tǒng)的用戶數(shù)量。使用性能測(cè)試工具模擬出與系統(tǒng)的訪問(wèn)用戶數(shù)相同的用戶，并模擬用戶的行為，那么得到的測(cè)試結(jié)果就能夠真實(shí)反映實(shí)際用戶訪問(wèn)時(shí)的系統(tǒng)性能表現(xiàn)。這里提到的在同一個(gè)時(shí)間段內(nèi)訪問(wèn)系統(tǒng)的用戶數(shù)量，也就是并發(fā)用戶數(shù)的其中一個(gè)概念。這個(gè)并發(fā)的概念通常在性能測(cè)試方法中用于從業(yè)務(wù)的角度模擬真實(shí)的用戶訪問(wèn)，體現(xiàn)的是業(yè)務(wù)并發(fā)用戶數(shù)。如果拋開(kāi)業(yè)務(wù)的層面，僅從服務(wù)器端所能承受的壓力來(lái)考慮，那么對(duì)C/S結(jié)構(gòu)的應(yīng)用來(lái)說(shuō)，毫無(wú)疑問(wèn)系統(tǒng)的性能表現(xiàn)主要由服務(wù)器端決定。顯然，當(dāng)越多的用戶同時(shí)使用系統(tǒng)，系統(tǒng)承受的壓力越大，系統(tǒng)的性能表現(xiàn)也就越差。而且，此時(shí)很可能出現(xiàn)由于用戶的同時(shí)訪問(wèn)而導(dǎo)致的資源爭(zhēng)用等問(wèn)題。這里提出“并發(fā)用戶數(shù)”的另一個(gè)概念。不從業(yè)務(wù)角度出發(fā)，而是從服務(wù)器端承受的壓力出發(fā)，它描述的是同時(shí)向服務(wù)器發(fā)出請(qǐng)求的客戶。這個(gè)概念一般結(jié)合并發(fā)測(cè)試（Concurrency Testing）使用，并體現(xiàn)服務(wù)器端承受的最大并發(fā)訪問(wèn)數(shù)。（2）估算公式在實(shí)際的性能測(cè)試工作中比較關(guān)心的是業(yè)務(wù)并發(fā)用戶數(shù)，也就是從業(yè)務(wù)角度設(shè)置比較合理的并發(fā)數(shù)。因此，下面的討論主要是針對(duì)業(yè)務(wù)并發(fā)用戶數(shù)（簡(jiǎn)稱并發(fā)用戶數(shù)）。根據(jù)參考文獻(xiàn)[6]中提出的用于估算平均并發(fā)用戶數(shù)的方法，首先對(duì)登錄會(huì)話（login session）進(jìn)行定義。登錄會(huì)話是由起始時(shí)間和結(jié)束時(shí)間定義的一段時(shí)間間隔。在這段時(shí)間內(nèi)保留有一個(gè)或多個(gè)系統(tǒng)資源。以需要用戶驗(yàn)證的應(yīng)用程序?yàn)槔?，一個(gè)登錄會(huì)話在用戶登入系統(tǒng)的時(shí)刻開(kāi)始，并于用戶注銷的時(shí)刻結(jié)束。每個(gè)由登錄會(huì)話創(chuàng)建的用戶會(huì)話都會(huì)消耗系統(tǒng)內(nèi)存，而且它們從開(kāi)始到結(jié)束的時(shí)間長(zhǎng)度都不同。這里，某一時(shí)間片上的并發(fā)用戶數(shù)由時(shí)間片中的用戶會(huì)話數(shù)來(lái)定義。 某一時(shí)間片上的并發(fā)用戶數(shù) The Number of Concurrent Users at A Particular Time Instant每個(gè)水平線段表示一個(gè)的登錄會(huì)話。因?yàn)閠0時(shí)刻有三個(gè)登錄會(huì)話，所以t0時(shí)刻的并發(fā)用戶數(shù)為3。一般的，從0到任意時(shí)刻T的時(shí)間間隔上，并發(fā)用戶的平均數(shù)C可表示為：C=所有登錄會(huì)話時(shí)間長(zhǎng)度的總和247。T當(dāng)0到T時(shí)刻的登錄會(huì)話總數(shù)為n，且登錄會(huì)話時(shí)間的平均長(zhǎng)度為L(zhǎng)時(shí)，則： C=nL/T （）當(dāng)要估算并發(fā)用戶數(shù)的峰值CP時(shí)，可以使用泊松分布對(duì)此獨(dú)立隨機(jī)事件進(jìn)行建模。參考文獻(xiàn)[6]給出的計(jì)算公式如下： CP≈ （）（3）使用建議參考文獻(xiàn)[6]提供的是一種可行但非最精確的方法。因?yàn)樵诠剑ǎ┖停ǎ┲腥匀灰浪恪安l(fā)用戶的平均數(shù)”和“登錄會(huì)話時(shí)間長(zhǎng)度”，而要精確估算這兩個(gè)值并不容易。另外，還要考慮到用戶的業(yè)務(wù)操作存在一定的時(shí)間集中性，即相對(duì)集中地分布在某個(gè)時(shí)間段內(nèi)而不是平均分布在整個(gè)考察的時(shí)間段內(nèi)?；谶@個(gè)方法，提出在使用公式時(shí)的一些建議，以便更精確地計(jì)算出并發(fā)用戶數(shù)。首先應(yīng)該以更細(xì)的時(shí)間粒度進(jìn)行考察。例如，可以設(shè)定1個(gè)小時(shí)為考察時(shí)間的粒度。對(duì)該即時(shí)通信系統(tǒng)，將一天的上班時(shí)間劃分為8個(gè)區(qū)間，這樣就可以解決前面提到業(yè)務(wù)操作存在的時(shí)間集中性問(wèn)題。其次要考慮典型的業(yè)務(wù)模式，因?yàn)椴煌膽?yīng)用就有不同的模式。例如，一個(gè)內(nèi)部系統(tǒng)一般在上班后30分鐘至1個(gè)小時(shí)內(nèi)會(huì)集中地出現(xiàn)用戶登錄；一個(gè)財(cái)務(wù)系統(tǒng)在每月中旬結(jié)賬日的前幾天會(huì)比較繁忙；一個(gè)公司門戶網(wǎng)站在重要消息發(fā)布的前后會(huì)有訪問(wèn)高峰；一個(gè)視頻點(diǎn)播系統(tǒng)會(huì)在休息時(shí)段有大量的用戶訪問(wèn)等等。因此，在考慮計(jì)算并發(fā)用戶時(shí)，可以結(jié)合系統(tǒng)所應(yīng)用的業(yè)務(wù)模式，多考慮一些可能發(fā)生的場(chǎng)景，并基于這些場(chǎng)景進(jìn)行估算。 即時(shí)通信系統(tǒng)性能測(cè)試方法論對(duì)性能測(cè)試來(lái)說(shuō)，如果沒(méi)有正確科學(xué)的方法論指導(dǎo)，性能測(cè)試很容易成為一種隨意的測(cè)試行為。而隨意進(jìn)行的性能測(cè)試很難取得實(shí)際作用和預(yù)期效果。下面給出本次即時(shí)通信系統(tǒng)性能測(cè)試過(guò)程中使用到的方法。 性能下降曲線分析法性能下降曲線實(shí)際上描述的是性能隨用戶數(shù)增長(zhǎng)而出現(xiàn)下降趨勢(shì)的曲線。而這里所說(shuō)的“性能”一般是指響應(yīng)時(shí)間，但也可以指吞吐量等其他數(shù)據(jù)。 一條基本的響應(yīng)時(shí)間性能下降曲線圖 A Basic Response Time Degradation Curve Chart這張圖描繪了用戶訪問(wèn)的時(shí)間與系統(tǒng)用戶負(fù)載之間的對(duì)比。左邊的縱軸是幾秒鐘內(nèi)端到端的響應(yīng)時(shí)間，而底部的橫軸則是訪問(wèn)系統(tǒng)的用戶總數(shù)。這張?zhí)厥獾膱D中還包含了數(shù)據(jù)表。隨著更多的用戶接入系統(tǒng)，圖中用戶訪問(wèn)的時(shí)間就如預(yù)料的情況那樣增加或減少了。圖中數(shù)據(jù)所生成的是最普遍的響應(yīng)時(shí)間性能曲線形狀。95%以上的曲線圖都會(huì)像該圖一樣。如果出現(xiàn)較大的偏差，主要原因應(yīng)從以下幾點(diǎn)考慮：（1）用戶群體模型不準(zhǔn)確。（2）編寫的腳本不具有用戶群體模型代表性。（3）測(cè)試的系統(tǒng)無(wú)法處理多用戶。（4）測(cè)試沒(méi)有真正對(duì)系統(tǒng)產(chǎn)生壓力。典型的響應(yīng)時(shí)間性能下降曲線可以劃分為以下幾個(gè)部分：（1）單用戶區(qū)域此時(shí)段是對(duì)系統(tǒng)單用戶的響應(yīng)時(shí)間。從圖中可以看出，單用戶的性能實(shí)際上比后面幾個(gè)級(jí)別的多用戶性能更慢。這是正常的。因?yàn)橛韶?fù)載生成工具生成的單用戶響應(yīng)通常都會(huì)稍慢于某些頁(yè)面的最佳性能，與負(fù)載生成工具的工作方式（比如線程）、高速緩存和休眠中的硬盤等有關(guān)。僅是單用戶接入頁(yè)面的這種情況可以比喻為在冰天雪地中駕駛汽車。如果汽車沒(méi)有上路前進(jìn)行暖車，那么車子的性能可能就會(huì)有些遲緩。所以一般情況下不應(yīng)使用單用戶負(fù)載作為后續(xù)負(fù)載測(cè)試的參照基準(zhǔn)。（2）性能平坦區(qū)在模仿10到100個(gè)用戶的區(qū)域范圍內(nèi)，可以看到系統(tǒng)獲得了更好的性能并在一段時(shí)間內(nèi)保持不變。在測(cè)試模型正確的前提下，系統(tǒng)能夠在這個(gè)區(qū)域達(dá)到期望的最佳性能而不需要對(duì)其進(jìn)行更多的性能調(diào)優(yōu)。任何位于性能平坦區(qū)的測(cè)試結(jié)果都可以作為后續(xù)負(fù)載測(cè)試的參照基準(zhǔn)或基線。根據(jù)參考文獻(xiàn)[7]提出的觀點(diǎn)，應(yīng)該以性能拐點(diǎn)之前最大用戶負(fù)載的15%為基準(zhǔn)。（3）壓力區(qū)域從圖中用戶負(fù)載在100到175之間的區(qū)域可以明顯地看到，隨著負(fù)載的增長(zhǎng)響應(yīng)時(shí)間開(kāi)始延長(zhǎng)。從技術(shù)上說(shuō)曲線下降的地方系統(tǒng)正處于壓力之下，但基本上還是能夠處理負(fù)載的。壓力區(qū)域在響應(yīng)時(shí)間開(kāi)始緩慢增長(zhǎng)的時(shí)候開(kāi)始，并在性能拐點(diǎn)結(jié)束。這里就是所謂系統(tǒng)性能“輕微下降”的地方。這也就意味著在此區(qū)域的負(fù)載增加了，響應(yīng)時(shí)間也會(huì)變長(zhǎng)，但增長(zhǎng)率不是很高。當(dāng)應(yīng)用軟件進(jìn)行了全面調(diào)整之后，即使在壓力區(qū)域加上最大的建議用戶負(fù)載，系統(tǒng)仍然能夠在高于此負(fù)載的情況下相對(duì)較好地運(yùn)行一段時(shí)間。（4）性能拐點(diǎn)超過(guò)175的用戶負(fù)載之后，曲線圖中的響應(yīng)時(shí)間開(kāi)始快速增長(zhǎng)。系統(tǒng)已不再能很好地處理負(fù)載了，接著很可能出現(xiàn)運(yùn)行不正常甚至不穩(wěn)定。響應(yīng)時(shí)間的這種變化經(jīng)常會(huì)很快地發(fā)生，并在傾斜度或趨勢(shì)上造成曲線急劇的變化。此處稱之為性能拐點(diǎn)。性能拐點(diǎn)處就是系統(tǒng)所能承受的極大負(fù)載。在性能測(cè)試中此處的負(fù)載已成為系統(tǒng)的關(guān)鍵瓶頸并值得去研究其細(xì)節(jié)，還要盡可能地對(duì)系統(tǒng)進(jìn)行調(diào)優(yōu)。對(duì)性能測(cè)試來(lái)說(shuō)，找到這些區(qū)域和拐點(diǎn)，也就可以找到性能瓶頸產(chǎn)生的地方。因此，對(duì)性能下降曲線分析法來(lái)說(shuō)，主要關(guān)注的是性能下降曲線上的各個(gè)區(qū)間和對(duì)應(yīng)的拐點(diǎn)。通過(guò)識(shí)別不同的區(qū)間和拐點(diǎn)，從而為性能瓶頸識(shí)別和調(diào)優(yōu)提供依據(jù)。 PTGM模型隨著被測(cè)試系統(tǒng)的日趨復(fù)雜，參考文獻(xiàn)[8]提出了一種對(duì)性能測(cè)試進(jìn)行管理的方法，該方法基于自動(dòng)化測(cè)試生命周期方法（Automated Test LiftCycle Methodology, ATLM）和被廣泛采用的TMap模型。這種方法是用的模型稱為性能測(cè)試過(guò)程通用模型（Performance Test General Model, PTGM）。PTGM模型是一個(gè)結(jié)構(gòu)化的過(guò)程模型。它將性能測(cè)試過(guò)程分為測(cè)試前期準(zhǔn)備、測(cè)試工具引入、測(cè)試計(jì)劃、測(cè)試設(shè)計(jì)與開(kāi)發(fā)、測(cè)試執(zhí)行和管理以及測(cè)試分析等六個(gè)步驟。 性能測(cè)試過(guò)程通用模型 Performance Testing General Model根據(jù)PTGM模型對(duì)性能測(cè)試過(guò)程的描述，下面分別對(duì)即時(shí)通信系統(tǒng)性能測(cè)試的各個(gè)階段進(jìn)行闡述。 測(cè)試前期準(zhǔn)備及工具引入在把握該系統(tǒng)的基本狀況之后，開(kāi)始進(jìn)行測(cè)試前期的準(zhǔn)備工作并引入測(cè)試工具。 系統(tǒng)基本功能的驗(yàn)證該系統(tǒng)進(jìn)行性能測(cè)試時(shí)已經(jīng)進(jìn)行了客戶端各功能的驗(yàn)收測(cè)試，因此在性能測(cè)試中不需要額外安排基礎(chǔ)功能驗(yàn)證。 測(cè)試工具需求確認(rèn)考慮到即時(shí)通信系統(tǒng)測(cè)試的要求，確定的測(cè)試工具需求如下：（1）支持HTTP、Jabber/XMPP協(xié)議層上的測(cè)試。（2）能監(jiān)控Linux服務(wù)器的主要性能計(jì)數(shù)器值，例如服務(wù)器的內(nèi)存使用狀況、CPU使用狀況、磁盤I/O情況等。（3）能監(jiān)控Windows服務(wù)器的主要性能計(jì)數(shù)器值