性能測試中如何定位性能瓶頸

性能測試的概念是什麼，基本目的是什麼，我想大家都基本清楚，不作詳述，總之，性能測試隻是測試過程中的一種方式，幫助我們的功能更好的運作，如果功能測試是可用，易用，滿足需求、使用者使用為目的，性能測試無非就是讓這些目的更流暢。沒有什麼專業的概念，無非實作兩個字：好用！

是以，性能測試這種測試方式在發生過程中，其中一個過渡性的工作，就是對執行過程中的問題，進行定位，對功能的定位，對負載的定位，最重要的，當然就是問題中說的“瓶頸”，接觸性能測試不深，更非專家，自己的了解，瓶頸産生在以下幾方面：

• 1、網絡瓶頸，如帶寬，流量等形成的網絡環境
• 2、應用服務瓶頸，如中間件的基本配置，CACHE等
• 3、系統瓶頸，這個比較常用：應用伺服器，資料庫伺服器以及客戶機的CPU，記憶體，硬碟等配置
• 4、資料庫瓶頸，以ORACLE為例，SYS中預設的一些參數設定
• 5、應用程式本身瓶頸，

針對網絡瓶頸，現在冒似很少，不過也不是沒有，首先想一下如果有網絡的阻塞，斷網，帶寬被其他資源占用，限速等情況，應用程式或系統會是什麼情況，針對WEB，無非是逾時，HTTP400，500之類的錯，針對一些用戶端程式，可能也是逾時，掉線，伺服器下發的，需要伺服器傳回的資訊擷取不到還有一種更明顯的情況，應該就是事務送出慢，如果封裝事務的代碼再不完善，一般造成的錯誤，無非就是資料送出不完整，或者因為網終原因+代碼缺陷造成重複性送出。如此綜合下來，肯定是考慮網絡有瓶頸，然後考慮網絡有問題時，怎樣去優化，是需要優化互動的一些代碼，還是接口之類的。

應用服務的瓶頸的定位，比較複雜，學習中，不過網上有很多資料可以參考的。一般像tomcat，weblogic之類的，有預設的設定，也有經過架構和維護人員進行試驗調試的一些值，這些值一般可以滿足程式釋出的需要，不必進行太多的設定，可能我們認識的最基本的就是JAVA_OPTS的設定，maxThreads，time_out之類的參數我們做借助LR，Jemeter或webload之類的工具，執行性能測試，尤其是對應用服務造成了壓力，如果應用服務有瓶頸，一般我們設定的log4j.properties，日志都會記錄下來。然後根據日志，去進一步确定應用服務的問題

系統瓶頸，這個定位雖說比較複雜，但是有很多前輩的經驗值參考，不作說明，相信用LR的同行，也可以從性能記數器中得出一些名額值，加上nagios，cacti，可以很明顯的看出系統哪些資源夠用，哪些資源明顯不夠用。不過，一般系統瓶頸的造成，是因為應用程式本身造成的。關于這點兒的分析和定位，就需要歸入應用程式本身瓶頸分析和定位了。

現在基本所有的東東，都離不開資料庫這個背景，資料庫的瓶頸實在是不知道是什麼概念，資料庫管理者的工作，資料庫管理者日常做的工作，可能就是有瓶頸定位的工作，比如：查詢一下V$sys_event，V$sysstat，v$syssql之類的表，比對一下日常正常情況下的監控資料，看一下有沒有異常等。其他方面，我也不是太了解。

應用程式瓶頸，這個是測試過程中最需要去關注的，需要測試人員和開發人員配合執行，然後定位，我這兒做的大都是執行性的，比如會有腳本去運作，開發人員會結合jprofiler之類的工具，去看一下堆周遊，線程剖析的情況确定哪兒有問題。大緻是這樣，沒有實際操作過

逐漸細化分析，先可以監控一些常見衡量CPU，記憶體，磁盤的性能名額，進行綜合分析，然後根據所測系統具體情況，進行初步問題定位，然後确定更詳細的監控名額來分析。

懷疑記憶體不足時：

方法1：

【監控名額】：Memory Available MBytes ，Memory的Pages/sec， page read/sec， Page Faults/sec

【參考值】：

如果 Page Reads/Sec 比率持續保持為 5，表示可能記憶體不足。

Page/sec 推薦00-20（如果伺服器沒有足夠的記憶體處理其工作負荷，此數值将一直很高。如果大于80，表示有問題）。

方法2：根據Physical Disk 值分析性能瓶頸

【監控名額】：Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length

【參考值】：%Disk Time建議門檻值90%

當記憶體不足時，有點程序會轉移到硬碟上去運作，造成性能急劇下降，而且一個缺少記憶體的系統常常表現出很高的CPU使用率，因為它需要不斷的掃描記憶體，将記憶體中的頁面移到硬碟上。

懷疑記憶體洩漏時

【監控名額】：Memory Available MBytes ，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time

【說明】：

Windows資源監控中，如果Process\Private Bytes計數器和Process\Working Set計數器的值在長時間内持續升高，同時Memory\Available bytes計數器的值持續降低，則很可能存在記憶體洩漏。記憶體洩漏應該通過一個長時間的，用來研究分析當所有記憶體都耗盡時，應用程式反應情況的測試來檢驗。

CPU分析

【監控名額】：

System %Processor Time CPU，Processor %Processor Time CPU

Processor%user time 和Processor%Privileged Time

system\Processor Queue Length

Context Switches/sec 和%Privileged Time

【參考值】：

System\%Total processor time不持續超過90%，如果伺服器專用于SQL Server，可接受的最大上限是80-85% ，合理使用的範圍在60%至70%。

Processor %Processor Time小于75%

system\Processor Queue Length值，小于CPU數量的總數+1

CPU瓶頸問題

1、System\%Total processor time如果該值持續超過90%，且伴随處理器阻塞，則說明整個系統面臨着處理器方面的瓶頸.

注：在某些多CPU系統中，該資料雖然本身并不大，但CPU之間的負載狀況極不均衡，此時也應該視作系統産生了處理器方面的瓶頸.

2、排除記憶體因素，如果Processor %Processor Time計數器的值比較大，而同時網卡和硬碟的值比較低，那麼可以确定CPU 瓶頸。（記憶體不足時，有點程序會轉移到硬碟上去運作，造成性能急劇下降，而且一個缺少記憶體的系統常常表現出很高的CPU使用率，因為它需要不斷的掃描記憶體，将記憶體中的頁面移到硬碟上。）

造成高CPU使用率的原因：

頻繁執行程式，複雜運算操作，消耗CPU嚴重

資料庫查詢語句複雜，大量的 where 子句，order by， group by 排序等，CPU容易出現瓶頸

記憶體不足，IO磁盤問題使得CPU的開銷增加

磁盤I/O分析

【監控名額】：PhysicalDisk/%Disk time，PhysicalDisk/%Idle Time，Physical Disk\ Avg.Disk Queue Length， Disk sec/Transfer

【參考值】：%Disk Time建議門檻值90%

Windows資源監控中，如果% Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec頁面讀取操作速率很低，則可能存在磁盤瓶徑。

Processor%Privileged Time該參數值一直很高，且如果在 Physical Disk 計數器中，隻有%Disk time 比較大，其他值都比較适中，硬碟可能會是瓶頸。若幾個值都比較大， 那麼硬碟不是瓶頸。若數值持續超過80%，則可能是記憶體洩露。如果 Physical Disk 計數器的值很高時該計數器的值（Processor%Privileged Time）也一直很高， 則考慮使用速度更快或效率更高的磁盤子系統。

Disk sec/Transfer 一般來說，該數值小于15ms為最好，介于15-30ms之間為良好，30-60ms之間為可以接受，超過60ms則需要考慮更換硬碟或是硬碟的RAID方式了.

Average Transaciton Response Time（事務平均響應時間）随着測試時間的變化，系統處理事務的速度開始逐漸變慢，這說明應用系統随着投産時間的變化，整體性能将會有下降的趨勢

Transactions per Second（每秒通過事務數/TPS）當壓力加大時，點選率/TPS曲線如果變化緩慢或者有平坦的趨勢，很有可能是伺服器開始出現瓶頸

Hits per Second（每秒點選次數）通過對檢視“每秒點選次數”，可以判斷系統是否穩定。系統點選率下降通常表明伺服器的響應速度在變慢，需進一步分析，發現系統瓶頸所在。

Throughput（吞吐率）可以依據伺服器的吞吐量來評估虛拟使用者産生的負載量，以及看出伺服器在流量方面的處理能力以及是否存在瓶頸。

Connections（連接配接數）當連接配接數到達穩定狀态而事務響應時間迅速增大時，添加連接配接可以使性能得到極大提高（事務響應時間将降低）

Time to First Buffer Breakdown（Over Time）（第一次緩沖時間細分（随時間變化））可以使用該圖确定場景或會話步驟運作期間伺服器或網絡出現問題的時間。

碰到過的性能問題：

• 1. 在高并發的情況下，産生的處理失敗（比如：資料庫連接配接池過低，伺服器連接配接數超過上限，資料庫鎖控制考慮不足等）
• 2. 記憶體洩露（比如：在長時間運作下，記憶體沒有正常釋放，發生當機等）
• 3. CPU使用偏離（比如：高并發導緻CPU使用率過高）
• 4. 日志列印過多，伺服器無硬碟空間

如何定位這些性能問題：

1. 檢視系統日志，日志是定位問題的不二法寶，如果日志記錄的全面，很容易通過日志發現問題。

比如，系統當機時，系統日志列印了某方法執行時抛出out of memory的錯誤，我們就可以順藤摸瓜，很快定位到導緻記憶體溢出的問題在哪裡。

2. 利用性能監控工具，比如：JAVA開發B/S結構的項目，可以通過JDK自帶的Jconsole，或者JProfiler，來監控伺服器性能，Jconsole可以遠端監控伺服器的CPU，記憶體，線程等狀态，并繪制變化曲線圖。

利用Spotlight可以監控資料庫使用情況。

我們需要關注的性能點有：CPU負載，記憶體使用率，網絡I/O等

3. 工具和日志隻是手段，除此之外，還需要設計合理的性能測試場景

具體場景有：性能測試，負載測試，壓力測試，穩定性測試，浪湧測試等

好的測試場景，能更加快速的發現瓶頸，定位瓶頸

4. 了解系統參數配置，可以進行後期的性能調優

除此以外，還想說個題外話，就是關于性能測試工具的使用問題

在剛開始用Loadrunner和JMeter的時候，做高并發測試時，都出現過沒有把伺服器壓垮，這兩個程式自己先倒下的情況。

如果遇到這個問題，可以通過遠端調用多個用戶端的服務，分散性能測試工具用戶端的壓力來解決。

說這個的目的是想說，做性能測試的時候，我們一定要確定瓶頸不要發生在我們自己的測試腳本和測試工具上。