性能調(diào)優(yōu)無疑是個(gè)龐大的話題，也是很多項(xiàng)目中非常重要的一環(huán)，性能調(diào)優(yōu)的難做是眾所周知的，畢竟性能調(diào)優(yōu)涵蓋的面實(shí)在是太多了，在這篇blog中我們蜻蜓點(diǎn)水般的來看看性能調(diào)優(yōu)這項(xiàng)龐大的工程都有些什么過程，同時(shí)也看看這些過程中常見的一些做法。
確定性能調(diào)優(yōu)的目標(biāo)
性能調(diào)優(yōu)，首先是要確定性能調(diào)優(yōu)的目標(biāo)是什么，如果現(xiàn)在應(yīng)用已經(jīng)滿足了需求，就沒必要去做性能調(diào)優(yōu)了，畢竟不經(jīng)過一個(gè)系統(tǒng)的過程，其實(shí)是無法確定你所做的性能調(diào)整是否真的調(diào)優(yōu)了性能，是否沒有造成應(yīng)用中其他的問題，所以確定性能目標(biāo)是非常重要的，在定義性能目標(biāo)的時(shí)候通常這么定義的呢：
1、最大并發(fā)數(shù)
2、Quality of Service
服務(wù)的質(zhì)量，在軟件系統(tǒng)方面我們認(rèn)為主要表現(xiàn)在請(qǐng)求的出錯(cuò)率，系統(tǒng)的load等。
3、最長響應(yīng)時(shí)間
對(duì)于任何請(qǐng)求所能承受的最大響應(yīng)時(shí)間。
4、TPS
每秒需要支持的最大事務(wù)數(shù)，最典型的指標(biāo)是：“某頁面最高需要支撐每秒7000次的訪問次數(shù)”。
例如一個(gè)web系統(tǒng)，需要定義出來的目標(biāo)是：
并發(fā)目標(biāo)：最高支撐200并發(fā)；
QoS：出錯(cuò)率須控制在萬分之一，系統(tǒng)的load最高只能到達(dá)10；
TPS：每秒完成7000次請(qǐng)求的處理；
最大響應(yīng)時(shí)間：最長允許的響應(yīng)時(shí)間為5秒。
至于請(qǐng)求的平均響應(yīng)時(shí)間這些就不在性能調(diào)優(yōu)目標(biāo)中定義，因?yàn)橐_(dá)到TPS的要求，響應(yīng)時(shí)間是必須要達(dá)到一個(gè)級(jí)別的，而且響應(yīng)時(shí)間隨著高并發(fā)是會(huì)出現(xiàn)劣化的。
當(dāng)然，還可以把性能指標(biāo)定到更為細(xì)節(jié)，例如某個(gè)方法的TPS在100并發(fā)時(shí)需要達(dá)到多少。
在確定好了性能目標(biāo)后，重要的就是如何來測(cè)量系統(tǒng)的性能了。
測(cè)量系統(tǒng)性能
對(duì)于新系統(tǒng)而言，需要評(píng)估出其正式運(yùn)行時(shí)的數(shù)據(jù)量的增長情況；而對(duì)于已運(yùn)行的系統(tǒng)，則需要根據(jù)監(jiān)控獲取到系統(tǒng)的運(yùn)行數(shù)據(jù)（例如高峰并發(fā)數(shù)、系統(tǒng)的響應(yīng)速度情況、系統(tǒng)的load、網(wǎng)絡(luò)流量、每類請(qǐng)求在總的請(qǐng)求中所占的百分比等）。
對(duì)于新系統(tǒng)而言，要評(píng)估出具體的性能相對(duì)來說稍微好做一點(diǎn)，因?yàn)榇藭r(shí)系統(tǒng)通常較為單純，數(shù)據(jù)量的增長也不可能是一夜之間增長的，因此基本可以按照一種正常的方法在測(cè)試環(huán)境評(píng)估出其正式運(yùn)行的性能。
而對(duì)于已運(yùn)行的系統(tǒng)而言，則較為麻煩，因?yàn)橥ǔ碇v要在測(cè)試環(huán)境中模擬正式運(yùn)行環(huán)境基本是不太可能的，因此這個(gè)時(shí)候通常要采取一些模擬的方法或更高壓力的方法來盡量更為準(zhǔn)確的評(píng)估出系統(tǒng)的性能。
在測(cè)試系統(tǒng)性能時(shí)，通?？刹捎玫姆椒ㄓ校?br />
1、單元測(cè)試；
可借助單元測(cè)試來測(cè)試某個(gè)請(qǐng)求的性能；
2、壓力測(cè)試；
壓力測(cè)試無疑是測(cè)量系統(tǒng)性能中最常采用的方式，根據(jù)定義的性能目標(biāo)對(duì)系統(tǒng)進(jìn)行壓力測(cè)試，以確定系統(tǒng)是否滿足性能要求，同時(shí)也可以根據(jù)壓力測(cè)試的結(jié)果來分析系統(tǒng)的瓶頸，進(jìn)而進(jìn)行對(duì)應(yīng)的調(diào)優(yōu)，可用于做壓力測(cè)試的工具還是不少的，像loadrunner、jmeter等等，不過壓力測(cè)試這個(gè)話題實(shí)在太大了，不在這里展開去講了，不過我也不怎么懂就是，呵呵。
分析系統(tǒng)性能瓶頸
根據(jù)測(cè)量系統(tǒng)性能的結(jié)果，多數(shù)是可以分析出系統(tǒng)性能的瓶頸，同時(shí)還可以結(jié)合像jvm堆棧、jprofiler、系統(tǒng)日志等來進(jìn)行進(jìn)一步的確定，另外也可以根據(jù)性能調(diào)優(yōu)人員的經(jīng)驗(yàn)，例如可以去了解開發(fā)人員是否采用了不適合的數(shù)據(jù)結(jié)構(gòu)等。
簡(jiǎn)單說一個(gè)線程分析的例子：
借助kill -3 pid來獲取到目前jvm的線程堆棧信息，特別需要關(guān)注的是里面wait for monitor這樣的線程，這種線程是指在等待鎖的線程，等待一兩分鐘后再次kill -3 pid，看看這些wait for monitor的線程的變化情況，這對(duì)于分析線程中是否存在不合理的競(jìng)爭(zhēng)過高的鎖的分析是非常重要的。
這一步無疑也是性能調(diào)優(yōu)過程中最難的一步了，分析系統(tǒng)性能瓶頸這種基本只能結(jié)合實(shí)際例子來講了，正確在后續(xù)抽取一兩個(gè)例子來進(jìn)行講解。
性能調(diào)優(yōu)
在分析出系統(tǒng)性能的瓶頸后，其實(shí)這一步相對(duì)來說還好做些，當(dāng)然，需要建立在對(duì)軟硬件知識(shí)都有很好的深入了解的基礎(chǔ)上，在這里列舉一些比較常見的性能調(diào)優(yōu)的手段，多數(shù)是抄來或google來的，自己在這方面的經(jīng)驗(yàn)還不多，希望大家多加指點(diǎn)，:)
Redhat Linux內(nèi)核
Redhat linux內(nèi)核版本升級(jí)到2.6，2.6和2.4的差別還是很多的，例如對(duì)epoll的支持、NPTL的采用；epoll的支持對(duì)于java而言也是很重要的，在高并發(fā)的情況下nio是否采用epoll還是有挺大的差別的；而NPTL的采用對(duì)于多線程程序而言更是極為重要。
另外需要關(guān)注像linux的File Handles是多少、network buffer是多少、MTU是多少、Memory Page size是多少等等。
JVM
JVM調(diào)優(yōu)的文章相對(duì)來說比較多，大家需要了解的主要是-Xms/-Xmx、并行GC、-XX:MaxPermSize/-XX:MaxNewSize、-XX:ThreadStackSize、NIO采用epoll等等。
簡(jiǎn)單的列這兩個(gè)，其實(shí)性能調(diào)優(yōu)的手段還有非常的多，例如簡(jiǎn)單的增加CPU、買更快速度的硬盤、增加內(nèi)存、提升網(wǎng)絡(luò)帶寬等這些從硬件角度下手的方式，還有像數(shù)據(jù)庫調(diào)優(yōu)、應(yīng)用服務(wù)器調(diào)優(yōu)等等。
暫時(shí)就寫這么些了，以后列一些具體的例子來寫，那樣更為清晰些，這樣的話更多的是講述一下過程，可以大概了解下做性能調(diào)優(yōu)應(yīng)該去學(xué)習(xí)的知識(shí)點(diǎn)，^_^，也歡迎有經(jīng)驗(yàn)的同學(xué)們貢獻(xiàn)出一些實(shí)例的分享。