1、網路瓶頸，如頻寬，流量等形成的網路環境

　　2、應用服務瓶頸，如中介軟體的基本配置，CACHE等

　　3、系統瓶頸，這個比較常用：應用伺服器，資料庫伺服器以及客戶機的CPU，記憶體，硬碟等配置

　　4、資料庫瓶頸，以ORACLE為例，SYS中預設的一些引數設定

　　5、應用程式本身瓶頸，這個是測試過程中最需要去關注的，需要測試人員和開發人員配合執行，然後定位

逐步細化分析，先可以監控一些常見衡量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. 瞭解系統引數配置，可以進行後期的效能調優

        最後要說的是：做效能測試的時候，我們一定要確保瓶頸不要發生在我們自己的測試指令碼和測試工具上。