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