性能測試這種測試方式在發生過程中，其中一個過渡性的工作，就是對執行過程中的問題，進行定位，對功能的定位，對負載的定位，最重要的，當然就是問題中說的“瓶頸”，接觸性能測試不深，更非專家，自己的理解，瓶頸產生在以下幾方面：
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. 了解系統參數配置，可以進行后期的性能調優
最后要說的是：做性能測試的時候，我們一定要確保瓶頸不要發生在我們自己的測試腳本和測試工具上。