【轉】java性能測試 問題定位

性能測試的概念是什麼，基本目的是什麼，我想你們都基本清楚，不做詳述，總之，性能測試只是測試過程當中的一種方式，幫助咱們的功能更好的運行，若是功能測試是可用，易用，知足需求、用戶使用爲目的，性能測試無非就是讓這些目的更流暢。沒有什麼專業的概念，無非實現兩個字：好用！
因此，性能測試這種測試方式在發生過程當中，其中一個過渡性的工做，就是對執行過程當中的問題，進行定位，對功能的定位，對負載的定位，最重要的，固然就是問題中說的「瓶頸」，接觸性能測試不深，更非專家，本身的理解，瓶頸產生在如下幾方面：

一、網絡瓶頸，如帶寬，流量等造成的網絡環境
二、應用服務瓶頸，如中間件的基本配置，CACHE等
三、系統瓶頸，這個比較經常使用：應用服務器，數據庫服務器以及客戶機的CPU，內存，硬盤等配置
四、數據庫瓶頸，以ORACLE爲例，SYS中默認的一些參數設置
五、應用程序自己瓶頸，

針對網絡瓶頸，如今冒似不多，不過也不是沒有，首先想一下若是有網絡的阻塞，斷網，帶寬被其餘資源佔用，限速等狀況，應用程序或系統會是什麼狀況，針對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瓶頸問題一、System\%Total processor time若是該值持續超過90%，且伴隨處理器阻塞，則說明整個系統面臨着處理器方面的瓶頸.
注：在某些多CPU系統中，該數據雖然自己並不大，但CPU之間的負載情況極不均衡，此時也應該視做系統產生了處理器方面的瓶頸.
二、排除內存因素，若是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的時候，作高併發測試時，都出現過沒有把服務器壓垮，這兩個程序本身先倒下的狀況。
若是遇到這個問題，能夠經過遠程調用多個客戶端的服務，分散性能測試工具客戶端的壓力來解決。
說這個的目的是想說，作性能測試的時候，咱們必定要確保瓶頸不要發生在咱們本身的測試腳本和測試工具上。