性能測試知多少：性能分析與調優的原理

最近一直糾結性能分析與調優如何下手，先從硬件開始，仍是先從代碼或數據庫。從操做系統（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： 性能調優不能以犧牲代碼的可讀性和可維護性爲代碼。