一、Processor
①%processor time
- %processor time:指系統執行非空閒時間的百分比。
- 閾值（ 正常範圍）：對於一個系統而言，%processor time的平均值小於85%，則沒有問題。如果其平均值超過85%或者其值持續超過95%，則懷疑處理器瓶頸
- 對於閾值，不同的公司可能有不同的要求，即使同一公司，可能也會因爲項目不同要區別對待，一般情況，小於75%到85%都視爲正常。
如果%processor time圖中偶爾走高，達到100%，要看其平均值，一般沒有問題。
②Processor queue length
性能測試過程中，雙核處理器一般視爲2個CPU
處理器隊列的閾值是：≤n+1,其中n是處理器個數
二、Memory
MemoryAvailable MBytes(可用物理內存值，單位是M)：如果windows系統中可用內存小於物理內存總數的1%，則內存可能是瓶頸。
- 系統可以在內存中存在大量軟錯誤的情況下，正常運行。但是如果系統存在大量的應錯誤，則會嚴重影響系統的性能。一般來講，硬錯誤（單位是個數）的閾值爲是內存的1%，即2G，硬錯誤不要超過20個。
- 如果pages/sec或者Page reads/sec（頁面的讀取率）值很高，則有可能內存不足。
三、System
系統吞吐量指的是系統在單位時間內可處理的事務的數量，是用於衡量系統性能的重要指標。
四、Physical Disk
性能調優的一個原則：儘量減少磁盤IO。因爲如果很大，會嚴重影響系統的性能。
Disk Read(Write)bytes/sec:如果該值超過幾十M，甚至上百M，則懷疑磁盤瓶頸。
五、Network Interface
- Byte total/sec的閾值：該值*8後再與帶寬的一半進行比較，如果小於帶寬的一半，則一般認爲網絡沒有瓶頸。帶寬的單位爲bits
六、實例分析
系統中硬件的瓶頸比軟件瓶頸容易解決（更換硬件），但是大部分的情況，都不是硬件問題，都表現爲硬件的問題，但實際上瓶頸是由軟件引起的，如程序代碼，SQL語句等等。比如沒有建立索引，需要全表掃描
①處理器分析
- %processor time平均值大於95
- processor queue length大於2+1
- 通過CPU表現可以確定該過程中存在瓶頸，此時的CPU已經不能滿足程序要求，可能需要擴展。
②判斷內存泄漏問題
- 圖中可以看到該程序並不存在內存泄漏的問題
- 內存泄漏問題經常出現在服務器長時間工作的時候，由於部分程序對內存沒有釋放，而將內存慢慢耗盡。也是提醒大家對系統穩定性測試的關注。
③應用程序
- context switchs/sec變化不大
- throughout曲線整體斜率不高
- 並且此股從而航context switches/sec已經超過了15000
- 程序需要進一步優化
應用服務器參數設置：
- 一般情況下，服務器的默認設置都比較低，當開發人員疏忽此問題時，有可能報錯，如連接池超過最大連接數時，則對繼續連接的用戶會報錯，拒絕連接。此時，將連接池中連接數調大即可。
- 調整參數時，最好單獨調整，除非是有關聯關係的數據；並且在調整時，要每次增加一部分，如50%左右，不要調整太大，逐步達到最優的效果，提升性能。
- 當系統的參數調整後，寂靜錄製好的腳本是否需要重錄腳本？—不需要，因爲業務邏輯沒有變化。只需要重新運行場景即可。
調優過程：調整某個參數–>運行場景–>調整某個參數—>運行場景….直到報告結果中性能有所提升
查看並
查看併發的出錯規律某系統50併發，失敗9個
- 100用戶併發，失敗59個
- 150用戶併發，失敗109個
因爲系統只支持上一次成功併發用戶數，如果上一次是25用戶併發，則系統支持25個用戶併發
爲什麼不是支持41併發？因爲41個用戶併發不是在正常環境下併發得到的，而是50用戶併發失敗的結果，不準確
④監控指標數據分析
圖形在Graphs—>Add New Item—>Add New Graph—>Web Resources—>Connections、Connections Per Second
分析：
集羣：將多態應用服務器聯合使用，當做一臺功能超級強大的服務器使用。需要使用相應的算法來管理集羣。例如F5算法
測試集羣時：要監控每一臺服務器，關注其負載是否均衡。即關注負載均衡。如果負載不均衡，如一臺服務器%processor time 90%,其他幾臺均爲20%，則該集羣負載均衡有問題，需要進行調整。
