性能測試需求和監(jiān)控分析性能測試需求分析的重要意義性能測試需求分析的正確性是整個性能測試工作的最基本前提

性能測試點的選取原則發(fā)生頻率非常高的（例如：139郵箱核心業(yè)務(wù)系統(tǒng)中的登錄、收發(fā)郵件等業(yè)務(wù)，它們在每天的業(yè)務(wù)總量中占到90%以上）關(guān)鍵程度非常高的（產(chǎn)品經(jīng)理認(rèn)為絕對不能出現(xiàn)問題的，如登錄等）資源占用非常嚴(yán)重的（導(dǎo)致磁盤I/O非常大的，例如某個業(yè)務(wù)進(jìn)行結(jié)果提交時需要向數(shù)十個表存取數(shù)據(jù)，或者一個查詢提交請求時會檢索出大量的數(shù)據(jù)記錄）性能測試需求描述要求

準(zhǔn)確如**系統(tǒng)必須在不超過10秒的響應(yīng)時間內(nèi),處理20起登錄任務(wù)。再如發(fā)郵件時間最大不超過5秒以及平均時間在2秒以內(nèi)。一致用戶和性能測試工程師對有關(guān)術(shù)語的理解要一致,如:并發(fā)用戶數(shù)、在線用戶數(shù)、注冊用戶數(shù):特定性能測試的需求一定是有條件的。檢查系統(tǒng)后臺關(guān)鍵業(yè)務(wù)數(shù)據(jù)10G、操作數(shù)據(jù)量為20K,

1500個用戶、500個并發(fā)用戶運行的負(fù)載下，連續(xù)運行12小時過程中,業(yè)務(wù)操作是否滿足性能需求。獲取性能測試需求的方法開發(fā)相關(guān)文檔相似項目性能需求業(yè)界公認(rèn)標(biāo)準(zhǔn)用戶使用模型二八原則服務(wù)訪問日志工作中的性能測試需求我們得到的測試需求往往是這么描述的：這個系統(tǒng)能否支撐200萬的vu（每天登錄系統(tǒng)的人次）。言下之意是：按照目前的硬件性能和數(shù)量，系統(tǒng)能否支撐200萬的vu。然而，我們了解的是吞吐量、響應(yīng)時間等指標(biāo)吞吐量：系統(tǒng)每秒能處理的請求數(shù)，這個指標(biāo)從服務(wù)器的視角，表征系統(tǒng)容量響應(yīng)時間：從請求發(fā)出到第一個字節(jié)返回所需要的時間，這個指標(biāo)從用戶的視角，表征系統(tǒng)響應(yīng)速度。常見的性能需求如下WEB首頁打開速度5s以下，web登陸速度15s以下。郵件服務(wù)支持50萬個在線用戶計費話單成功率達(dá)到99.999%以上。在100個并發(fā)用戶的高峰期，郵箱的基本功能，處理能力至少達(dá)到10TPS系統(tǒng)能在高于實際系統(tǒng)運行壓力1倍的情況下，穩(wěn)定的運行12小時這個系統(tǒng)能否支撐100萬的vu（每天登錄系統(tǒng)的人次）工作中的性能測試需求怎么辦：只能由我們根據(jù)經(jīng)驗，把200萬vu轉(zhuǎn)化成一系列的指標(biāo)。響應(yīng)時間：根據(jù)國外的一些資料，一般操作的響應(yīng)時間為2，5，8秒，2秒內(nèi)優(yōu)秀，5秒內(nèi)良好，8秒內(nèi)可接受，其它一些特殊的操作，如上傳，下載可以依據(jù)用戶體驗的情況，延長響應(yīng)時間。吞吐量：可以根據(jù)已經(jīng)上線的類似產(chǎn)品進(jìn)行估計。或者，采用80/20原則進(jìn)行估計。我們經(jīng)常使用的是80/20原則。工作中的性能測試需求怎么辦：只能由我們根據(jù)經(jīng)驗，把200萬vu轉(zhuǎn)化成一系列的指標(biāo)。響應(yīng)時間：根據(jù)國外的一些資料，一般操作的響應(yīng)時間為2，5，8秒，2秒內(nèi)優(yōu)秀，5秒內(nèi)良好，8秒內(nèi)可接受，其它一些特殊的操作，如上傳，下載可以依據(jù)用戶體驗的情況，延長響應(yīng)時間。吞吐量：可以根據(jù)已經(jīng)上線的類似產(chǎn)品進(jìn)行估計。或者，采用80/20原則進(jìn)行估計。我們經(jīng)常使用的是80/20原則。工作中的性能測試需求

80/20原則，又稱帕累托效應(yīng)，比如，80%的社會財富掌握在20%的人手里。應(yīng)用于測試：從vu計算吞吐量根據(jù)80/20原則，80%的用戶會在20%的繁忙時間內(nèi)登陸。則繁忙時間每秒大概會有（2000000*80%）/(24*3600*20%)=100個用戶登陸，也就是說，登陸操作的吞吐量是100TPS工作中的性能測試需求雖然已經(jīng)有了響應(yīng)時間和吞吐量指標(biāo)，但是測試需求還是不明確的。我們的測試目的是什么？是驗證當(dāng)前硬件和軟件配置能否支撐200萬vu？是測試當(dāng)前的硬件和軟件配置最多能支撐多少vu?

是幫助開發(fā)尋找性能瓶頸？工作中的性能測試需求根據(jù)我們的經(jīng)驗，開發(fā)的需求往往是這樣的，^_^：首先，請你們驗證能否支撐200萬vu。如果不能支撐，請找一下性能瓶頸。主要性能瓶頸解決后，請估計能支撐多少vu，如果不到200w，請估計要加多少機器。如果能支撐200萬，請再加壓，看看達(dá)到300萬vu的時候，系統(tǒng)的性能。這么一細(xì)化，需求基本明確了。性能測試案例分析SMTP發(fā)郵件峰值TPS按照139郵箱20000萬注冊用戶，其中日活躍用戶數(shù)為1.5%的規(guī)模計算：日活躍用戶=20000*1.5%=300萬日活躍用戶人均每天發(fā)6封郵件，用戶使用客戶端收發(fā)郵件比例20%，則：每天發(fā)郵件投遞量=300萬*6*20%=360萬封根據(jù)139郵箱業(yè)務(wù)模型表，每天忙時集中郵件系數(shù)0.15，郵件平均峰值系數(shù)2,則：峰值郵件量=3600000*0.15*2/3600=300封/秒性能測試案例分析去年全年處理“WEB登錄”交易約100萬筆，考慮到3年后交易量遞增到每年200萬筆。假設(shè)每年交易量集中在8個月，每個月20個工作日，每個工作日8小時，試采用80～20原理估算系統(tǒng)服務(wù)器高峰期“WEB登錄”的交易吞吐量應(yīng)達(dá)到怎樣的一個處理能力200萬/8=25萬/月25萬/20=1.25萬/日1.25萬*80%/(8*20%*3600)=1.74TPS性能監(jiān)控-cpuCPU也是一種硬件資源，和任何其他硬件設(shè)備一樣也需要驅(qū)動和管理程序才能使用，我們可以把內(nèi)核的進(jìn)程調(diào)度看作是CPU的管理程序，用來管理和分配CPU資源，合理安排進(jìn)程搶占CPU，并決定哪個進(jìn)程該使用CPU、哪個進(jìn)程該等待。打工仔接受和完成多少任務(wù)并向老板匯報了（中斷）；打工仔和老板溝通、協(xié)商每項工作的工作進(jìn)度（上下文切換）；打工仔的工作列表是不是都有排滿（可運行隊列）；打工仔工作效率如何，是不是在偷懶（CPU利用率）。性能監(jiān)控-cpu監(jiān)控的兩種方式

LR自帶的性能結(jié)果分析

Liunx自帶的監(jiān)控命令-vmstat,mpstat,psCPU利用率，如果CPU有100％利用率，那么應(yīng)該到達(dá)這樣一個平衡：65％－70％UserTime，30％－35％SystemTime，0％－5％IdleTime；上下文切換，上下文切換應(yīng)該和CPU利用率聯(lián)系起來看，如果能保持上面的CPU利用率平衡，大量的上下文切換是可以接受的；可運行隊列，每個可運行隊列不應(yīng)該有超過1－3個線程（每處理器），比如：雙處理器系統(tǒng)的可運行隊列里不應(yīng)該超過6個線程。性能監(jiān)控-cpu參數(shù)介紹：r，可運行隊列的線程數(shù)，這些線程都是可運行狀態(tài)，只不過CPU暫時不可用；b，被blocked的進(jìn)程數(shù)，正在等待IO請求；in，被處理過的中斷數(shù)cs，系統(tǒng)上正在做上下文切換的數(shù)目us，用戶占用CPU的百分比sys，內(nèi)核和中斷占用CPU的百分比wa，所有可運行的線程被blocked以后都在等待IO，這時候CPU空閑的百分比id，CPU完全空閑的百分比性能監(jiān)控-cpu雙核的機器從上面的數(shù)據(jù)可以看出幾點：interrupts（in）非常高，contextswitch（cs）比較低，說明這個CPU一直在不停的請求資源；usertime（us）一直保持在80％以上，而且上下文切換較低（cs），說明某個進(jìn)程可能一直霸占著CPU；runqueue（r）在4個。性能監(jiān)控-cpu從上面的數(shù)據(jù)可以看出幾點：contextswitch（cs）比interrupts（in）要高得多，說明內(nèi)核不得不來回切換進(jìn)程；進(jìn)一步觀察發(fā)現(xiàn)systemtime（sy）很高而usertime（us）很低，而且加上高頻度的上下文切換（cs），說明正在運行的應(yīng)用程序調(diào)用了大量的系統(tǒng)調(diào)用（systemcall）；runqueue（r）在14個線程以上，按照這個測試機器的硬件配置（四核），應(yīng)該保持在12個以內(nèi)。性能監(jiān)控-cpu

LR自帶的性能結(jié)果分析%ProcessorTimeCPU利用率，該計數(shù)器最為常用，可以查看處理器是否處于飽和狀態(tài)，如果該值持續(xù)超過95%，就表示當(dāng)前系統(tǒng)的瓶頸為CPU，可以考慮增加一個處理器或更換一個性能更好的處理器。（參考值：<80%）l

%PriviliagedTimeCPU在特權(quán)模式下處理線程所花的時間百分比。一般的系統(tǒng)服務(wù)，進(jìn)程管理，內(nèi)存管理等一些由操作系統(tǒng)自行啟動的進(jìn)程屬于這類l

%UserTime與%PrivilegedTime計數(shù)器正好相反，指的是在用戶狀態(tài)模式下（即非特權(quán)模式）的操作所花的時間百分比。如果該值較大，可以考慮是否通過算法優(yōu)化等方法降低這個值。如果該服務(wù)器是數(shù)據(jù)庫服務(wù)器，導(dǎo)致此值較大的原因很可能是數(shù)據(jù)庫的排序或是函數(shù)操作消耗了過多的CPU時間，此時可以考慮對數(shù)據(jù)庫系統(tǒng)進(jìn)行優(yōu)化。表示耗費CPU的數(shù)據(jù)庫操作，如排序，執(zhí)行aggregatefunctions等。如果該值很高，可考慮增加索引，盡量使用簡單的表聯(lián)接，水平分割大表格等方法來降低該值。l

%DPCTime處理器在網(wǎng)絡(luò)處理上消耗的時間，該值越低越好。越低越好。在多處理器系統(tǒng)中，如果這個值大于50%并且Processor:%ProcessorTime非常高，加入一個網(wǎng)卡可能會提高性能，提供的網(wǎng)絡(luò)已經(jīng)不飽和。性能監(jiān)控-內(nèi)存虛擬內(nèi)存（VirtualMemory）把計算機的內(nèi)存空間擴展到硬盤，物理內(nèi)存（RAM）和硬盤的一部分空間（SWAP）組合在一起作為虛擬內(nèi)存為計算機提供了一個連貫的虛擬內(nèi)存空間，好處是我們擁有的內(nèi)存”變多了“，可以運行更多、更大的程序，壞處是把部分硬盤當(dāng)內(nèi)存用整體性能受到影響，硬盤讀寫速度要比內(nèi)存慢幾個數(shù)量級，并且RAM和SWAP之間的交換增加了系統(tǒng)的負(fù)擔(dān)。介紹和性能監(jiān)測有關(guān)的兩個內(nèi)核進(jìn)程：kswapd和pdflush:kswapddaemon用來檢查pages_high和pages_low，如果可用內(nèi)存少于pages_low，kswapd就開始掃描并試圖釋放32個頁面，并且重復(fù)掃描釋放的過程直到可用內(nèi)存大于pages_high為止。掃描的時候檢查3件事：1）如果頁面沒有修改，把頁放到可用內(nèi)存列表里；2）如果頁面被文件系統(tǒng)修改，把頁面內(nèi)容寫到磁盤上；3）如果頁面被修改了，但不是被文件系統(tǒng)修改的，把頁面寫到交換空間。pdflushdaemon用來同步文件相關(guān)的內(nèi)存頁面，把內(nèi)存頁面及時同步到硬盤上。比如打開一個文件，文件被導(dǎo)入到內(nèi)存里，對文件做了修改后并保存后，內(nèi)核并不馬上保存文件到硬盤，由pdflush決定什么時候把相應(yīng)頁面寫入硬盤，這由一個內(nèi)核參數(shù)vm.dirty_background_ratio來控制，比如下面的參數(shù)顯示臟頁面（dirtypages）達(dá)到所有內(nèi)存頁面10％的時候開始寫入硬盤

#/sbin/sysctl-nvm.dirty_background_ratio10性能監(jiān)控-內(nèi)存頁面類型

Linux中內(nèi)存頁面有三種類型：Readpages，只讀頁（或代碼頁），那些通過主缺頁中斷從硬盤讀取的頁面，包括不能修改的靜態(tài)文件、可執(zhí)行文件、庫文件等。當(dāng)內(nèi)核需要它們的時候把它們讀到內(nèi)存中，當(dāng)內(nèi)存不足的時候，內(nèi)核就釋放它們到空閑列表，當(dāng)程序再次需要它們的時候需要通過缺頁中斷再次讀到內(nèi)存。Dirtypages，臟頁，指那些在內(nèi)存中被修改過的數(shù)據(jù)頁，比如文本文件等。這些文件由pdflush負(fù)責(zé)同步到硬盤，內(nèi)存不足的時候由kswapd和pdflush把數(shù)據(jù)寫回硬盤并釋放內(nèi)存。Anonymouspages，匿名頁，那些屬于某個進(jìn)程但是又和任何文件無關(guān)聯(lián)，不能被同步到硬盤上，內(nèi)存不足的時候由kswapd負(fù)責(zé)將它們寫到交換分區(qū)并釋放內(nèi)存。性能監(jiān)控-內(nèi)存監(jiān)控的兩種方式

LR自帶的性能結(jié)果分析

Liunx自帶的監(jiān)控命令-vmstat,top,psswpd，已使用的SWAP空間大小，KB為單位；free，可用的物理內(nèi)存大小，KB為單位；buff，物理內(nèi)存用來緩存讀寫操作的buffer大小，KB為單位；cache，物理內(nèi)存用來緩存進(jìn)程地址空間的cache大小，KB為單位；si，數(shù)據(jù)從SWAP讀取到RAM（swapin）的大小，KB為單位；so，數(shù)據(jù)從RAM寫到SWAP（swapout）的大小，KB為單位；bi，磁盤塊從文件系統(tǒng)或SWAP讀取到RAM（blocksin）的大小，block為單位；bo，磁盤塊從RAM寫到文件系統(tǒng)或SWAP（blocksout）的大小，block為單位。wa，所有可運行的線程被blocked以后都在等待IO，這時候CPU空閑的百分比性能監(jiān)控-內(nèi)存Cache：高速緩存，位于CPU與主內(nèi)存間的容量較小但速度很高的存儲器，指待寫入磁盤的緩存數(shù)據(jù)。Cached值很大，說明緩存文件數(shù)很多，如果頻繁訪問到的文件被cached，磁盤讀I/O就會小Buffer：緩沖區(qū)，一個用于存儲速度不同步的設(shè)備或優(yōu)先級不同的設(shè)備之間傳輸數(shù)據(jù)的區(qū)域，指已經(jīng)從磁盤讀取有待后續(xù)使用的緩存數(shù)據(jù)可用內(nèi)存=系統(tǒng)free內(nèi)存+buffers+cached性能監(jiān)控-內(nèi)存由上面的輸出結(jié)果可以看到：●用做緩沖區(qū)（buff）和快速緩存（Cache）的物理內(nèi)存不斷地增加，而空閑的物理內(nèi)存（free）不斷地減少，證明系統(tǒng)中運行的進(jìn)程正在不斷地消耗物理內(nèi)存?！褚呀?jīng)使用的虛擬內(nèi)存（swpd）不斷增加，而且存在著大量的頁面交換（si和so），證明物理內(nèi)存已經(jīng)不能滿足系統(tǒng)需求，系統(tǒng)必須把物理內(nèi)存的頁面交換到磁盤中去。由此可以得到這樣的結(jié)論：該主機上的物理內(nèi)存已經(jīng)不能滿足系統(tǒng)運行的需要，內(nèi)存已成為該系統(tǒng)性能的一個瓶頸。性能監(jiān)控-內(nèi)存

LR自帶的性能結(jié)果分析

PageFaults/sec當(dāng)處理器在內(nèi)存中讀取某一頁出現(xiàn)錯誤時，就會產(chǎn)生缺頁中斷，也就是pageFault。如果這個頁位于內(nèi)存的其他位置，這種錯誤稱為軟錯誤，用TransitionFault/sec

來衡量；如果這個頁位于硬盤上，必須從硬盤重新讀取，這個錯誤成為硬錯誤。硬錯誤會使系統(tǒng)的運行效率很快將下來。PageFaults/sec這個計數(shù)器就表示每秒鐘處理的錯誤頁數(shù)，包括硬錯誤和軟錯誤。l

PageReads/sec表示為了解決硬錯誤而從硬盤上讀取的頁數(shù)。為了解析對內(nèi)存的引用，必須讀取頁文件的次數(shù)。閾值為>5.越低越好。大數(shù)值表示磁盤讀而不是緩存讀。l

Page/sec表明由于硬件頁面錯誤而從磁盤取出的頁面數(shù)，或由于頁面錯誤而寫入磁盤以釋放工作集空間的頁面數(shù)。一般如果pages/sec持續(xù)高于幾百，那么您應(yīng)該進(jìn)一步研究頁交換活動。有可能需要增加內(nèi)存，以減少換頁的需求(你可以把這個數(shù)字乘以4k就得到由此引起的硬盤數(shù)據(jù)流量)。Pages/sec的值很大不一定表明內(nèi)存有問題，而可能是運行使用內(nèi)存映射文件的程序所致l

AvailableMbytes剩余的可用物理內(nèi)存，單位是兆字節(jié)（參考值：>=10%）用物理內(nèi)存數(shù).如果AvailableMbytes的值很小，則說明計算機上總的內(nèi)存可能不足，或某程序沒有釋放內(nèi)存。l

CatheBytes文件系統(tǒng)的緩存（默認(rèn)為50%的可用物理內(nèi)存）性能監(jiān)控-IO監(jiān)控的兩種方式

LR自帶的性能結(jié)果分析

Liunx自帶的監(jiān)控命令-iostat磁盤通常是計算機最慢的子系統(tǒng)，也是最容易出現(xiàn)性能瓶頸的地方，因為磁盤離CPU距離最遠(yuǎn)而且CPU訪問磁盤要涉及到機械操作，比如轉(zhuǎn)軸、尋軌等。訪問硬盤和訪問內(nèi)存之間的速度差別是以數(shù)量級來計算的，就像1天和1分鐘的差別一樣。

I/O即輸入/輸出(Input/Output)，是在主存和外部設(shè)備(如磁盤驅(qū)動器、終端和網(wǎng)絡(luò))之間拷貝數(shù)據(jù)的過程。輸入操作時從I/O設(shè)備拷貝數(shù)據(jù)到主存，而輸出操作是從主存拷貝數(shù)據(jù)到I/O設(shè)備。性能監(jiān)控-IOrrqm/s:每秒進(jìn)行merge的讀操作數(shù)目。即delta(rmerge)/swrqm/s:每秒進(jìn)行merge的寫操作數(shù)目。即delta(wmerge)/sr/s:每秒完成的讀I/O設(shè)備次數(shù)。即delta(rio)/sw/s:每秒完成的寫I/O設(shè)備次數(shù)。即delta(wio)/srsec/s:每秒讀扇區(qū)數(shù)。即delta(rsect)/swsec/s:每秒寫扇區(qū)數(shù)。即delta(wsect)/srkB/s:每秒讀K字節(jié)數(shù)。是rsect/s的一半，因為每扇區(qū)大小為512字節(jié)。wkB/s:每秒寫K字節(jié)數(shù)。是wsect/s的一半。avgrq-sz:平均每次設(shè)備I/O操作的數(shù)據(jù)大小(扇區(qū))。即delta(rsect+wsect)/delta(rio+wio)avgqu-sz:平均I/O隊列長度。即delta(aveq)/s/1000(因為aveq的單位為毫秒)。await:平均每次設(shè)備I/O操作的等待時間(毫秒)。即delta(ruse+wuse)/delta(rio+wio)svctm:平均每次設(shè)備I/O操作的服務(wù)時間(毫秒)。即delta(use)/delta(rio+wio)％util:一秒中有百分之多少的時間用于I/O操作，或者說一秒中有多少時間I/O隊列是非空的。即delta(use)/s/1000(因為use的單位為毫秒)性能監(jiān)控-IO1.如果rkb/s和wkb/s值很高，說明系統(tǒng)短時間內(nèi)正在做大批量的數(shù)據(jù)讀寫操作.連續(xù)大量的IO操作一般出現(xiàn)在數(shù)據(jù)庫應(yīng)用系統(tǒng)中2.IOPS的效能,可用每秒讀寫I/O字節(jié)數(shù)除以每秒讀寫IOPS數(shù)得出,比如：rkB/s除以r/swkB/s除以w/s7200是140,15000是200,生產(chǎn)環(huán)境用的是1萬轉(zhuǎn)，所以是167生產(chǎn)用服務(wù)硬盤不會小于10000轉(zhuǎn)的，所以不用考慮那么低轉(zhuǎn)速的硬盤3.如果％util接近100％，說明產(chǎn)生的I/O請求太多，I/O系統(tǒng)已經(jīng)滿負(fù)荷，該磁盤可能存在瓶頸。4.Iostat命令輸出await，await指：每一個IO請求的處理平均時間（單位是毫秒）。這里可以理解為I/O響應(yīng)時間，一般系統(tǒng)I/O相應(yīng)時間低于5秒鐘，10秒鐘比較大了。性能監(jiān)控-IO

LR自帶的性能結(jié)果分析

PhysicalDisk（磁盤）l

%DiskTime表示磁盤驅(qū)動器為讀取或?qū)懭胝埱筇峁┓?wù)所用的時間百分比，PageReads/sec和%DiskTime及Avg.DiskQueueLength。如果頁面讀取操作速率很低，同時%DiskTime和Avg.DiskQueueLength的值很高，則可能有磁盤瓶徑。但是，如果隊列長度增加的同時頁面讀取速率并未降低，則內(nèi)存不足。另外兩個都比較適中，硬盤可能會是瓶頸。l

AverageDiskQueueLength表示磁盤讀取和寫入請求提供服務(wù)所用的時間百分比，可以通過增加磁盤構(gòu)造磁盤陣列來提高性能（<=磁盤數(shù)的2倍）讀取和寫入請求(為所選磁盤在實例間隔中列隊的)的平均數(shù)。該值應(yīng)不超過磁盤數(shù)的1.5~2倍。要提高性能，可增加磁盤。注意：一個RaidDisk實際有多個磁盤。不應(yīng)當(dāng)超過物理磁盤數(shù)量的2倍,正常值<0.5l

AverageDiskReadQueueLength表示磁盤讀取請求的平均數(shù)l

AverageDiskwriteQueueLength表示磁盤寫入請求的平均數(shù)l

AverageDisk

sec/Read磁盤中讀取數(shù)據(jù)的平均時間，單位是秒l

AverageDisk

sec/Transer磁盤中寫入數(shù)據(jù)的平均時間，單位是秒，一般來說，定義該值小于15ms最為優(yōu)異，介于15-30ms之間為良好，30-60ms之間為可以接受，超過60ms則需要考慮更換硬盤或硬盤的RAID方式了性能監(jiān)控-中間件中間件

tomcat，weblogic，jboss，Apache我們把Tomcat的調(diào)整可以分為兩類來詳細(xì)描述：調(diào)整非Tomcat組件，例如Tomcat運行的操作系統(tǒng)和運行Tomcat的java虛擬自身調(diào)整修改Tomcat自身的參數(shù)，調(diào)整Tomcat配置文件中的參數(shù)。性能監(jiān)控-中間件

JAVA虛擬機性能優(yōu)化通過命令行的方式改變虛擬機使用內(nèi)存的大小。如下表所示有兩個參數(shù)用來設(shè)置虛擬機使用內(nèi)存的大小。參數(shù)描述-Xms<size>JVM初始化堆的大小-Xmx<size>JVM堆的最大值這兩個值的大小一般根據(jù)需要進(jìn)行設(shè)置。初始化堆的大小執(zhí)行了虛擬機在啟動時向系統(tǒng)申請的內(nèi)存的大小。一般而言，這個參數(shù)不重要。但是有的應(yīng)用程序在大負(fù)載的情況下會急劇地占用更多的內(nèi)存，此時這個參數(shù)就是顯得非常重要，如果虛擬機啟動時設(shè)置使用的內(nèi)存比較小而在這種情況下有許多對象進(jìn)行初始化，虛擬機就必須重復(fù)地增加內(nèi)存來滿足使用。由于這種原因，我們一般把-Xms和-Xmx設(shè)為一樣大，而堆的最大值受限于系統(tǒng)使用的物理內(nèi)存。一般使用數(shù)據(jù)量較大的應(yīng)用程序會使用持久對象，內(nèi)存使用有可能迅速地增長。當(dāng)應(yīng)用程序需要的內(nèi)存超出堆的最大值時虛擬機就會提示內(nèi)存溢出，并且導(dǎo)致應(yīng)用服務(wù)崩潰。因此一般建議堆的最大值設(shè)置為可用內(nèi)存的最大值的80%。Tomcat默認(rèn)可以使用的內(nèi)存為128MB，在較大型的應(yīng)用項目中，這點內(nèi)存是不夠的，需要調(diào)大。Windows下，在文件{tomcat_home}/bin/catalina.bat，Unix下，在文件{tomcat_home}/bin/catalina.sh的前面，增加如下設(shè)置：JAVA_OPTS='-Xms【初始化內(nèi)存大小】-Xmx【可以使用的最大內(nèi)存】'需要把這個兩個參數(shù)值調(diào)大。例如：JAVA_OPTS='-Xms256m-Xmx512m'表示初始化內(nèi)存為256MB，可以使用的最大內(nèi)存為512MB。另外需要考慮的是Java提供的垃圾回收機制。虛擬機的堆大小決定了虛擬機花費在收集垃圾上的時間和頻度。收集垃圾可以接受的速度與應(yīng)用有關(guān)，應(yīng)該通過分析實際的垃圾收集的時間和頻率來調(diào)整。如果堆的大小很大，那么完全垃圾收集就會很慢，但是頻度會降低。如果你把堆的大小和內(nèi)存的需要一致，完全收集就很快，但是會更加頻繁。調(diào)整堆大小的的目的是最小化垃圾收集的時間，以在特定的時間內(nèi)最大化處理客戶的請求。在基準(zhǔn)560TD(E測試的時候，為保證最好的性能，要把堆的大小設(shè)大，保證垃圾收集不在整個基準(zhǔn)測試的過程中出現(xiàn)。如果系統(tǒng)花費很多的時間收集垃圾，請減小堆大小。一次完全的垃圾收集應(yīng)該不超過3-5秒。如果垃圾收集成為瓶頸，那么需要指定代的大小，檢查垃圾收集的詳細(xì)輸出，研究垃圾收集參數(shù)對性能的影響。一般說來，你應(yīng)該使用物理內(nèi)存的80%作為堆大小。當(dāng)增加處理器時，記得增加內(nèi)存，因為分配可以并行進(jìn)行，而垃圾收集不是并行的。性能監(jiān)控-中間件

自身調(diào)整禁用DNS查詢當(dāng)web應(yīng)用程序向要記錄客戶端的信息時，它也會記錄客戶端的IP地址或者通過域名服務(wù)器查找機器名轉(zhuǎn)換為IP地址。DNS查詢需要占用網(wǎng)絡(luò)，并且包括可能從很多很遠(yuǎn)的服務(wù)器或者不起作用的服務(wù)器上去獲取對應(yīng)的IP的過程，這樣會消耗一定的時間。為了消除DNS查詢對性能的影響我們可以關(guān)閉DNS查詢，方式是修改server.xml文件中的enableLookups參數(shù)值：Tomcat4<ConnectorclassName="org.apache.coyote.tomcat4.CoyoteConnector"port="80"minProcessors="5"maxProcessors="75"enableLookups="false"redirectPort="8443"acceptCount="100"debug="0"connectionTimeout="20000"useURIValidationHack="false"disableUploadTimeout="true"/>Tomcat5<Connectorport="80"maxThreads="150"minSpareThreads="25"maxSpareThreads="75"enableLookups="false"redirectPort="8443"acceptCount="100"debug="0"connectionTimeout="20000"disableUploadTimeout="true"/>除非你需要連接到站點的每個HTTP客戶端的機器名，否則我們建議在生產(chǎn)環(huán)境上關(guān)閉DNS查詢功能?？梢酝ㄟ^Tomcat以外的方式來獲取機器名。這樣不僅節(jié)省了網(wǎng)絡(luò)帶寬、查詢時間和內(nèi)存，而且更小的流量會使日志數(shù)據(jù)也會變得更少，顯而易見也節(jié)省了硬盤空間。對流量較小的站點來說禁用DNS查詢可能沒有大流量站點的效果明顯性能監(jiān)控-中間件

自身調(diào)整調(diào)整線程數(shù)另外一個可通過應(yīng)用程序的連接器（Connector）進(jìn)行性能控制的的參數(shù)是創(chuàng)建的處理請求的線程數(shù)。Tomcat使用線程池加速響應(yīng)速度來處理請求。在Java中線程是程序運行時的路徑，是在一個程序中與其它控制線程無關(guān)的、能夠獨立運行的代碼段。它們共享相同的地址空間。多線程幫助程序員寫出CPU最大利用率的高效程序，使空閑時間保持最低，從而接受更多的請求。Tomcat4中可以通過修改minProcessors和maxProcessors的值來控制線程數(shù)。這些值在安裝后就已經(jīng)設(shè)定為默認(rèn)值并且是足夠使用的，但是隨著站點的擴容而改大這些值。minProcessors服務(wù)器啟動時創(chuàng)建的處理請求的線程數(shù)應(yīng)該足夠處理一個小量的負(fù)載。也就是說，如果一天內(nèi)每秒僅發(fā)生5次單擊事件，并且每個請求任務(wù)處理需要1秒鐘，那么預(yù)先設(shè)置線程數(shù)為5就足夠了。但在你的站點訪問量較大時就需要設(shè)置更大的線程數(shù)，指定為參數(shù)maxProcessors的值。maxProcessors的值也是有上限的，應(yīng)防止流量不可控制（或者惡意的服務(wù)攻擊），從而導(dǎo)致超出了虛擬機使用內(nèi)存的大小。如果要加大并發(fā)連接數(shù)，應(yīng)同時加大這兩個參數(shù)。webserver允許的最大連接數(shù)還受制于操作系統(tǒng)的內(nèi)核參數(shù)設(shè)置，通常Windows是2000個左右，Linux是1000個左右。在Tomcat5對這些參數(shù)進(jìn)行了調(diào)整，請看下表：屬性名描述maxThreadsTomcat使用線程來處理接收的每個請求。這個值表示Tomcat可創(chuàng)建的最大的線程數(shù)。acceptCount指定當(dāng)所有可以使用的處理請求的線程數(shù)都被使用時，可以放到處理隊列中的請求數(shù)，超過這個數(shù)的請求將不予處理。connnectionTimeout網(wǎng)絡(luò)連接超時，單位：毫秒。設(shè)置為0表示永不超時，這樣設(shè)置有隱患的。通常可設(shè)置為30000毫秒。minSpareThreadsTomcat初始化時創(chuàng)建的線程數(shù)。maxSpareThreads一旦創(chuàng)建的線程超過這個值，Tomcat就會關(guān)閉不再需要的socket線程最好的方式是多設(shè)置幾次并且進(jìn)行測試，觀察響應(yīng)時間和內(nèi)存使用情況。在不同的機器、操作系統(tǒng)或虛擬機組合的情況下可能會不同，而且并不是所有人的web站點的流量都是一樣的，因此沒有一刀切的方案來確定線程數(shù)的值。性能監(jiān)控-數(shù)據(jù)庫監(jiān)控的兩種方式

LR自帶的性能結(jié)果分析監(jiān)控工具-sitecope，OracleEm，數(shù)據(jù)庫快照工具數(shù)據(jù)庫調(diào)優(yōu)原則避免過多復(fù)雜的SQL腳本，減少系統(tǒng)的解析過程避免過多的無用的計算，例如：死循環(huán)避免浪費內(nèi)存空間沒有必要的SQL腳本，導(dǎo)致內(nèi)存不足內(nèi)存中計算和訪問速度很快盡可能的減少磁盤的訪問的數(shù)據(jù)量，該原則是PLSQL優(yōu)化中重要思想。盡可能的減少磁盤的訪問的次數(shù)，該原則是PLSQL優(yōu)化中重要思想。性能監(jiān)控-問題分析實例1

如果系統(tǒng)由于應(yīng)用程序代碼效率低下或者系統(tǒng)結(jié)構(gòu)設(shè)計有缺陷而導(dǎo)致大量的上下文切換(contextswitches/sec顯示的上下文切換次數(shù)太高)那么就會占用大量的系統(tǒng)資源,如果系統(tǒng)的吞吐量降低并且CPU的使用率很高,并且此現(xiàn)象發(fā)生時切換水平在15000以上,那么意味著上下文切換次數(shù)過高.

從圖的整體看.contextswitches/sec變化不大,throughout曲線的斜率較高,并且此時的contextswitches/sec已經(jīng)超過了15000.程序還是需要進(jìn)一步優(yōu)化.性能監(jiān)控-問題分析實例2判斷CPU瓶頸如果processorqueuelength顯示的隊列長度保持不變(>=2)個并且處理器的利用率%Processortime超過90%,那么很可能存在處理器瓶頸.如果發(fā)現(xiàn)processorqueuelength顯示的隊列長度超過CPU核數(shù)的1-3倍,而處理器的利用率卻一直很低,或許更應(yīng)該去解決處理器阻塞問題,這里處理器一般不是瓶頸.%processortime平均值大于95,processorqueuelength大于CPU核數(shù)的1-3倍.可以確定CPU瓶頸.此時的CPU已經(jīng)不能滿足程序需要.急需擴展.性能監(jiān)控-問題分析實例3判斷內(nèi)存泄露問題內(nèi)存問題主要檢查應(yīng)用程序是否存在內(nèi)存泄漏,如果發(fā)生了內(nèi)存泄漏,process\privatebytes計數(shù)器和process\workingset計數(shù)器的值往往會升高,同時avaiablebytes的值會降低.內(nèi)存泄漏應(yīng)該通過一個長時間的,用來研究分析所有內(nèi)存都耗盡時,應(yīng)用程序反應(yīng)情況的測試來檢驗.圖中可以