性能分析

性能結果分析是性能測試中的一個重要部分，同時也是一個難點。因爲不一樣的軟件系統，不一樣的性能指標，結果分析方法都是不同的。須要具體問題具體分析。下面將闡述一些性能分析的方法與建議。

1 性能分析的目的

 1）找出系統瓶頸（硬件、軟件）

2）提出性能優化方案

3）達到合理的硬件和軟件配置

4）使系統資源使用達到最大平衡

2 常見性能瓶頸徵兆

  在性能測試執行過程當中，咱們須要觀察和了解系統的運行狀態，若是出現如下徵兆，則表示系統可能存在瓶頸。 

1) 持續緩慢：應用程序一直特別慢，改變負載，對總體響應時間影響不多； 

2) 隨着時間推動愈來愈慢：負載不變，隨着時間推動愈來愈慢，可能到達某個閾值，系統被鎖定或出現大量錯誤而崩潰； 

3) 隨着負載增長愈來愈慢：每增長若干用戶，系統明顯變慢，用戶離開系統，系統恢復原狀； 

4) 零星掛起或異常錯誤：多是負載或某些緣由，用戶看到頁面沒法完成並掛起，沒法消除； 

5) 可預見的鎖定：一旦出現掛起或錯誤，就加速出現，直到系統徹底鎖定。一般要重啓系統才解決。 

6) 忽然混亂：系統一直運行正常，多是一個小時或三天以後，系統忽然出項大量錯誤或鎖定。

3 性能數據解讀建議

  性能分析過程也是一個解讀數據的過程，讀懂了數據你就能知道問題出在何處。隨着經驗的累積將會很容易判斷問題的根源，甚至在開發階段就能對可能出現問題的點打預防針。

性能指標類型	標準	性能瓶頸徵兆	分析工具
TPS及其波動範圍	1.Tps符合性能目標 2.Tps軌跡波動平穩	1.TPS有明顯的大幅波動，不穩定。例如TPS軌跡緩慢降低，緩慢上升後驟降，呈瀑布型，呈矩形，分時間段有規律的波動，無規律的波動等。這些TPS的波動軌跡反映出被測試的性能點存在性能瓶頸，須要性能測試工程師與開發工程師查找性能瓶頸的緣由。 2. TPS軌跡比較平穩，可是也存在波動現象。該類波動不明顯，很難直接肯定是否存在性能瓶頸。咱們須要根據其餘指標來進行判斷。	Jmeter/loadrunner
響應時間	90%平均事務響應時間<性能目標	1.關注高峯負載時，用戶操做響應時間；   2.關注數據庫增量，對用戶操做響應時間的影響。	Jmeter/loadrunner
Web\DB服務器內存		1.很高的換頁率 2.進程進入不活動狀態; 3.交換區全部磁盤的活動次數太高; 4.太高的全局系統CPU利用率; 5.內存不夠出錯(out of memory errors)	Nmon/top/vmstat
WEB\DB服務器CPU	合理使用的範圍在60%至70%	1.很慢的響應時間 2.CPU空閒時間爲零 3.太高的用戶佔用CPU時間 4.太高的系統佔用CPU時間 5.長時間的有很長的運行進程隊列	Nmon/vmstat/top
WEB\DB服務器磁盤I/O	Iowait<30%	1.太高的磁盤利用率； 2.太長的磁盤等待隊列； 3.等待磁盤I/O的時間所佔的百分率過高； 4.過高的物理I/O速率； 5.太低的緩存命中率； 6.太長的運行進程隊列，但CPU卻空閒；	Nmon/sar/iostat
Oracle數據庫		1.緩存命中率小於0.90 2.top 10sql耗時高 Oracle數據庫的分析和優化，是一門專門的技術，進一步的分析可查相關資料，也能夠查看數據庫性能分析工具AWR章節。	AWR

 

4 如何定位性能問題

性能問題的定位排查過程比較複雜，能夠採用「拆分問題，隔離分析」的方法進行分析，即逐步定位、從外到內、從表及裏、逐層分解、隔離排除。如下分析順序可供參考。

日誌分析--->服務器硬件瓶頸---〉網絡瓶頸（對局域網，能夠不考慮）---〉服務器操做系統瓶頸（參數配置）---〉中間件瓶頸（參數配置，web服務器等）---〉數據庫及應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等）。

以上過程並非每一個分析中都須要的，要根據測試目的和要求來肯定分析的深度。整個過程當中，要配套使用一些健康工具和日誌進行。如： JDK自帶的Jconsole，或者JProfiler，來監控服務器性能，oracle的監控工具awr等，具體工具能夠參考工具篇。

另外，作性能測試的時候，咱們必定要確保瓶頸不要發生在本身的測試腳本和測試工具上。

基於上述思想的指導，在具體執行層面，能夠參考以下分析過程：

首先，當咱們系統有問題的時候，咱們不要急於去調查咱們代碼，這個毫無心義。咱們首要須要看的是操做系統的報告。看看操做系統的CPU利用率，看看內存使用率，看看操做系統的IO，還有網絡的IO，網絡連接數，等等。經過觀察這些數據，咱們就能夠知道咱們的軟件的性能基本上出在哪裏。好比：

1） 先看CPU利用率，若是CPU利用率不高，可是系統的Throughput和Latency上不去了，這說明咱們的程序並無忙於計算，而是忙於別的一些事，好比IO。（另外，CPU的利用率還要看內核態的和用戶態的，內核態的一上去了，整個系統的性能就下來了。而對於多核CPU來講，CPU 0是至關關鍵的，若是CPU0的負載高，那麼會影響其它核的性能，由於CPU各核間是須要有調度的，這靠CPU0完成）

2） 而後，咱們能夠看一下IO大不大，IO和CPU通常是反着來的，CPU利用率高則IO不大，IO大則CPU就小。關於IO，咱們要看三個事，一個是磁盤文件IO，一個是驅動程序的IO（如：網卡），一個是內存換頁率。這三個事都會影響系統性能。

3） 而後，查看一下網絡帶寬使用狀況，在Linux下，你可使用iftop，iptraf，ntop，tcpdump這些命令來查看。或是用Wireshark來查看。

4） 若是CPU不高，IO不高，內存使用不高，網絡帶寬使用不高。可是系統的性能上不去。這說明你的程序有問題，好比，你的程序被阻塞了。多是由於等那個鎖，多是由於等某個資源，或者是在切換上下文。

經過了解操做系統的性能，咱們才知道性能的問題，好比：帶寬不夠，內存不夠，TCP緩衝區不夠，等等，不少時候，不須要調整程序的，只須要調整一下硬件或操做系統的配置就能夠了。具體配置項的調優，能夠參考配置項調優參考章節。

接下來，咱們須要使用性能檢測工具，也就是使用某個Profiler來差看一下咱們程序的運行性能。如：Java的JProfiler/TPTP/CodeProProfiler，GNU的gprof，IBM的PurifyPlus，Intel的VTune，AMD的接下來，咱們須要使用性能檢測工具，也就是使用某個Profiler來差看一下咱們程序的運行性能。如：Java的JProfiler/TPTP/CodePro Profiler，GNU的gprof，IBM的PurifyPlus，Intel的VTune，AMD的CodeAnalyst，還有Linux下的OProfile/perf，後面兩個可讓你對你的代碼優化到CPU的微指令級別，若是你關心CPU的L1/L2的緩存調優，那麼你須要考慮一下使用VTune。使用這些Profiler工具，可讓你程序中各個模塊函數甚至指令的不少東西，如：運行的時間，調用的次數，CPU的利用率，等等。這些東西對咱們來講很是有用。

咱們重點觀察運行時間最多，調用次數最多的那些函數和指令。這裏注意一下，對於調用次數多可是時間很短的函數，你可能只須要輕微優化一下，你的性能就上去了（好比：某函數一秒種被調用100萬次，你想一想若是你讓這個函數提升0.01毫秒的時間，這會給你帶來多大的性能）。

使用Profiler有個問題咱們須要注意一下，由於Profiler會讓你的程序運行的性能變低，像PurifyPlus這樣的工具會在你的代碼中插入不少代碼，會致使你的程序運行效率變低，從而無法測試出在高吞吐量下的系統的性能，對此，通常有兩個方法來定位系統瓶頸：

1）在你的代碼中本身作統計，使用微秒級的計時器和函數調用計算器，每隔10秒把統計log到文件中。

2）分段註釋你的代碼塊，讓一些函數空轉，作Hard Code的Mock，而後再測試一下系統的Throughput和Latency是否有質的變化，若是有，那麼被註釋的函數就是性能瓶頸，再在這個函數體內註釋代碼，直到找到最耗性能的語句。

最後再說一點，對於性能測試，不一樣的Throughput會出現不一樣的測試結果，不一樣的測試數據也會有不一樣的測試結果。因此，用於性能測試的數據很是重要，性能測試中，咱們須要觀測試不一樣Throughput的結果。

4 常見性能問題參考

  下面是整理收集的一些常見問題列表，不全，也許並不對，你們能夠補充指正。

類別	常見性能問題
操做系統類	1. Sys的CPU使用率太高 2. User的CPU使用率太高，持續大於80%以上 3.可用物理內存不足致使內存溢出 4. 磁盤空間不足致使交易處理失敗，性能降低 5. TCP/IP鏈接數限制致使用戶請求失敗 6.磁盤IO使用比較繁忙，持續大於70%
中間件類	經常使用主流中間件：Tomcat、apache、nginx、Weblogic、Jboss等  1.線程不回收致使溢出，引起宕機 2.數據庫鏈接池不釋放致使溢出 3.JVM內存參數設置不合理，新生代過大或偏小 4.永久代設置太小，致使棧溢出 5.其它問題
應用程序類	1. 程序響應時間超長 2. JAVA程序內存溢出，內存中存放大量數據對象 3. JAVA程序循環嵌套過多，過於精細的查詢條件，子查詢間等待超時 4.程序中存在死循環引發線程死鎖，致使CPU使用率達到100% 5.某些返回結果未定義處理方式，致使線程等待，不釋放，CPU使用率高
數據庫類	1.SGA分配不合理，須要具體狀況具體分析 2.使用全表掃描 3.對於查詢業務比較多的表，未創建索引，或創建的索引不合理，在索引列上使用IS NULL和IS NOT NULL 4.存在數據庫死鎖致使數據庫鏈接超時或不釋放。 5.存在過於複雜的計算，致使CPU、內存和IO使用率較高。 6. 數據庫讀寫過於頻繁，致使IO使用率比較高
其餘問題	1.網絡問題，被測試環境網絡環境小於100M 2. 客戶端問題等等