最近一直糾結性能分析與調優如何下手，先從硬件開始，還是先從代碼或數據庫。從操作系統（CPU調度，內存管理，進程調度，磁盤I/O）、網絡、協議（HTTP， TCP/IP ），還是從應用程序代碼，數據庫調優，中間件配置等方面入手。
單一個中間件又分web中間件（apache 、IIS），應用中間件（tomcat 、weblogic 、webSphere ）等，雖然都是中間件，每一樣拎出來往深了學都不是一朝一夕之功。但調優對于每一項的要求又不僅僅是“知道”或“會使用”這么簡單。起碼要達到“如何更好的使用”。
常看到性能測試書中說，性能測試不單單是性能測試工程師一個人的事兒。需要DBA 、開發人員、運維人員的配合完成。但是在不少情況下性能測試是由性能測試人員獨立完成的，退一步就算由其它人員的協助，了解系統架構的的各個模塊對于自身的提高也有很大幫助，同進也更能得到別人的尊重。
再說性能調優之前，我們有必要再提一下進行測試的目的，或者我們進行性能測試的初衷是什么？
能力驗證：驗證某系統在一定條件具有什么樣的能力。
能力規劃：如何使系統達到我們要求的性能能力。
應用程序診斷：比如內存泄漏，通過功能測試很難發現，但通過性能測試卻很容易發現。
性能調優：滿足用戶需求，進一步進行系統分析找出瓶頸，優化瓶頸，提高系統整體性能。
一般系統的瓶頸
性能測試調優需要先發現瓶頸，那么系統一般會存在哪些瓶頸：
硬件上的性能瓶頸：
一般指的是CPU、內存、磁盤I/O 方面的問題，分為服務器硬件瓶頸、網絡瓶頸（對局域網可以不考慮）、服務器操作系統瓶頸（參數配置）、中間件瓶頸（參數配置、數據庫、web服務器等）、應用瓶頸（SQL 語句、數據庫設計、業務邏輯、算法等）。
應用軟件上的性能瓶頸：
一般指的是應用服務器、web 服務器等應用軟件，還包括數據庫系統。
例如：中間件weblogic 平臺上配置的JDBC連接池的參數設置不合理，造成的瓶頸。
應用程序上的性能瓶頸：
一般指的是開發人員新開發出來的應用程序。
例如，程序架構規劃不合理，程序本身設計有問題（串行處理、請求的處理線程不夠），造成系統在大量用戶方位時性能低下而造成的瓶頸。
操作系統上的性能瓶頸：
一般指的是windows、UNIX、Linux等操作系統。
例如，在進行性能測試，出現物理內存不足時，虛擬內存設置也不合理，虛擬內存的交換效率就會大大降低，從而導致行為的響應時間大大增加，這時認為操作系統上出現性能瓶頸。
網絡設備上的性能瓶頸：
一般指的是防火墻、動態負載均衡器、交換機等設備。
例如，在動態負載均衡器上設置了動態分發負載的機制，當發現某個應用服務器上的硬件資源已經到達極限時，動態負載均衡器將后續的交易請求發送到其他負載較輕的應用服務器上。在測試時發現，動態負載均衡器沒有起到相應的作用，這時可以認為網絡瓶頸。
性能測試出現的原因及其定位十分復雜，這里只是簡單介紹常見的幾種瓶頸類型和特征，而性能測試所需要做的就是根據各種情況因素綜合考慮，然后協助開發人員\DBA\運維人員一起定位性能瓶頸。
一般性能調優步驟
一般性能問題調優的步驟：
步驟一：確定問題
應用程序代碼：在通常情況下，很多程序的性能問題都是寫出來的，因此對于發現瓶頸的模塊，應該首先檢查一下代碼。
數據庫配置：經常引起整個系統運行緩慢，一些諸如oracle 的大型數據庫都是需要DBA進行正確的參數調整才能投產的。
操作系統配置：不合理就可能引起系統瓶頸。
硬件設置：硬盤速度、內存大小等都是容易引起瓶頸的原因，因此這些都是分析的重點。
網絡：網絡負載過重導致網絡沖突和網絡延遲。
步驟二：確定問題
當確定了問題之后，我們要明確這個問題影響的是響應時間吞吐量，還是其他問題？是多數用戶還是少數用戶遇到了問題？如果是少數用戶，這幾個用戶與其它用戶的操作有什么不用？系統資源監控的結果是否正常？CPU的使用是否到達極限？I/O 情況如何？問題是否集中在某一類模塊中？ 是客戶端還是服務器出現問題？ 系統硬件配置是否夠用？實際負載是否超過了系統的負載能力？ 是否未對系統進行優化？
通過這些分析及一些與系統相關的問題，可以對系統瓶頸有更深入的了解，進而分析出真正的原因。
步驟三：確定調整目標和解決方案
得高系統吞吐理，縮短響應時間，更好地支持并發。
步驟四：測試解決方案
對通過解決方案調優后的系統進行基準測試。（基準測試是指通過設計科學的測試方法、測試工具和測試系統，實現對一類測試對象的某項性能指標進行定量的和可對比的測試）
步驟五：分析調優結果
系統調優是否達到或者超出了預定目標？系統是整體性能得到了改善，還是以系統某部分性能來解決其他問題。調優是否可以結束了。
最后，如果達到了預期目標，調優工作就基本可以結束了。
下面算是一個技巧，如面試官問到一個性能問題假設，我不知道性能問題出在哪兒時，可以按照這個思路回答^_^
● 查找瓶頸時按以下順序，由易到難。
服務器硬件瓶頸---〉網絡瓶頸（對局域網，可以不考慮）---〉服務器操作系統瓶頸（參數配置）---〉中間件瓶頸（參數配置，數據庫，web服務器等）---〉應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等）
注：以上過程并不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力（并發用戶數、數據量）下，系統的硬件瓶頸在哪兒就夠了。
● 分段排除法 很有效
性能測試調優應該注意的要點：
→ 要點1：在應用系統的設計開發過程中，應始終把性能放在考慮的范圍內。
→ 要點2：確定清晰明確的性能目標是關鍵。
→ 要點3：必須保證調優后的程序運行正確。
→ 要點4：系統的性能更大程度上取決于良好的設計，調優技巧只是一個輔助手段。
→ 要點5：調優過程是迭代漸進的過程，每一次調優的結果都要反饋到后續的代碼開發中去。
→ 要點6：性能調優不能以犧牲代碼的可讀性和可維護性為代碼。
--------------------------------------------------------------------------------
本文只介紹了一些性能調優的要關注的東西以及性能調優的一般要點。并沒有具體說如何對系統的每個部件進行調優，如何要細說也不是一兩書能說清的，對知識面的要求也非常高，是我目前的能力無法觸摸的。
這里做個總結：
《性能測試知多少》系列基本完結，雖然時間拉得比較長，但我沒有把它給太監。雖然內容都在空談性能測試理論知識，但我認為這些東西對于你從事性能測試工作必不可少。當然，我在“ jmeter基礎 ” 與“ loadrunner 技巧 ” 中講解兩個性能測試工具的使用。
如果我的這些文章對于想了解和學習性能的同學帶來一絲的幫助，我將非常開心。我不是高手，只是和你一起熱愛測試技術的初學者，只是比較喜歡總結；也時常為前途迷茫，但我知道只要斷去學習，路就在前方。我后面會整理性能調優的相關文章。
相關鏈接：
性能測試知多少----性能測試分類之我見
性能測試知多少---并發用戶
性能測試知多少---吞吐量
性能測試知多少---響應時間
性能測試知多少---了解前端性能
性能測試知多少---性能測試工具原理與架構
性能測試知多少---性能測試流程
性能測試知多少---性能需求分析
性能測試知多少---性能測試計劃
性能測試知多少---系統架構分析
性能測試知多少--系統計數器與硬件分析
性能測試知多少---測試環境搭建
性能測試知多少---測試工具介紹