性能測試中會遇到的瓶頸(2)

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. 在高并發的情況下，產生的處理失?。ū热纾簲祿爝B接池過低，服務器連接數超過上限，數據庫鎖控制考慮不足等）
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的時候，做高并發測試時，都出現過沒有把服務器壓垮，這兩個程序自己先倒下的情況。

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

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

原文轉自：https://www.cnblogs.com/linyu51/p/13187083.html