一、軟件性能測試需要監控哪些關鍵指標？
軟件性能測試的目的主要有以下三點：
Ø 評價系統當前性能，判斷系統是否滿足預期的性能需求。
Ø 尋找軟件系統可能存在的性能問題，定位性能瓶頸並解決問題。
Ø 判定軟件系統的性能表現，預見系統負載壓力承受力，在應用部署之前，評估系統性能。
而對於用戶來說，則最關注的是當前系統：
Ø 是否滿足上線性能要求？
Ø 系統極限承載如何？
Ø 系統穩定性如何？
因此，針對以上性能測試的目的以及用戶的關注點，要達到以上目的並回答用戶的關注點，就必須首先執行性能測試並明確需要收集、監控哪些關鍵指標，通常情 況下，性能測試監控指標主要分為：資源指標和系統指標，如下圖所示，資源指標與硬件資源消耗直接相關，而系統指標則與用戶場景及需求直接相關。
能測試監控關鍵指標說明：
Ø 資源指標
CPU使用率：指用戶進程與系統進程消耗的CPU時間百分比，長時間情況下，一般可接受上限不超過85%。
內存利用率：內存利用率=（1-空閑內存/總內存大小）*100%，一般至少有10%可用內存，內存使用率可接受上限為85%。
磁盤I/O: 磁盤主要用於存取數據，因此當說到IO操作的時候，就會存在兩種相對應的操作，存數據的時候對應的是寫IO操作，取數據的時候對應的是是讀IO操作，一般使用% Disk Time（磁盤用於讀寫操作所占用的時間百分比）度量磁盤讀寫性能。
網絡帶寬：一般使用計數器Bytes Total/sec來度量，Bytes Total/sec表示為發送和接收字節的速率，包括幀字符在內。判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬比較。
Ø 系統指標：
並發用戶數：某一物理時刻同時向系統提交請求的用戶數。
在線用戶數：某段時間內訪問系統的用戶數，這些用戶並不一定同時向系統提交請求。
平均響應時間：系統處理事務的響應時間的平均值。事務的響應時間是從客戶端提交訪問請求到客戶端接收到服務器響應所消耗的時間。對於系統快速響應類頁面，一般響應時間為3秒左右。
事務成功率：性能測試中，定義事務用於度量一個或者多個業務流程的性能指標，如用戶登錄、保存訂單、提交訂單操作均可定義為事務，如下圖所示：
單位時間內系統可以成功完成多少個定義的事務，在一定程度上反應了系統的處理能力，一般以事務成功率來度量，計算公式如下所示：
超時錯誤率：主要指事務由於超時或系統內部其它錯誤導致失敗占總事務的比率。
二、如何監控關鍵指標？
Ø 資源指標監控
主要針對各服務器系統平台（Windows、Linux、Unix等）資源使用進行監控。
可以使用系統自帶的性能監控工具或者第三方工具進行監控，如Windows系統自帶的“系統性能監視器”，如下圖所示：
Linux系統下，free、vmstat、sar、iostat等命令監控內存、CPU、磁盤IO等的使用情況，如下圖所示：
第三方監控工具，如spotlight，spotlight是quest公司開發的一款可以針對多種系統平台及數據庫進行監控的可視化工具，如下圖所示：
Nmon是IBM提供的監控AIX和Linux系統資源的免費工具，可以對收集的資源信息通過Excel進行統計分析形成直觀的統計圖，如下圖所示：
Ø 系統指標監控
系統指標監控一般通過性能測試工具（如LoadRunner、Jmeter等）以圖形化方式監控，如下圖所示，並發用戶數與平均響應時間關系圖。
三、如何分析監控的關鍵指標？
通過第二部分監控收集到性能度量關鍵指標，如何進行分析，並判斷是否存在性能瓶頸呢？以下主要從資源指標與系統指標兩方面進行闡述。
Ø 資源指標分析
判斷CPU是否是瓶頸的方法：一般情況下CPU滿負荷工作，有時候並不能判定為CPU出現瓶頸，比如Linux 總是試圖要CPU盡可能的繁忙，使得任務的吞吐量最大化，即CPU盡可能最大化使用。因此，一般判斷CPU為瓶頸，主要從兩方面：一是CPU空閑持續為 0，二是運行隊列大於CPU核數（經驗值3-4倍），即可判定存在瓶頸，對於CPU高消耗主要由什么引起的，可能是應用程序不合理造成，也可能是硬件資源 不足，需要具體問題具體分析，比如問題SQL語句引起，則需要跟蹤並優化引起CPU使用過高的SQL語句。
判斷內存是否是瓶頸的方法：一般至少有10%可用內存，內存使用率可接受上限為85%。當空閑內存變小時，系統開始頻繁地調動磁盤頁面文件，空閑內存過小可能是內存不足或內存泄漏引起，需要根據系統實際情況監控分析。
判斷磁盤I/O是否是瓶頸的方法：磁盤I/O對於數據庫服務器、文件服務器、流媒體服務器系統來說，更容易成為瓶頸，一般從以下幾個方面對磁盤I/O進行分析判斷：
① 計算每磁盤I/O數
每磁盤I/O數可用來與磁盤的I/O能力進行對比，如果經過計算得到的每磁盤I/O數超過了磁盤標稱的I/O能力，則說明確實存在磁盤的性能瓶頸，每磁盤I/O計算方法如下表：
| RAID類型 |
計算方法 |
| RAID0 |
(Reads+Writes)/Numbers of Disks |
| RAID1 |
(Reads+2*Writes)/2 |
| RAID5 |
[Reads+(4*Writes)] /Numbers of Disks |
| RAID10 |
[Reads+(2*Writes)] /Numbers of Disks |
② 監控磁盤讀寫，如果磁盤長時間進行大數據量讀寫操作，且cpu等待超過20%，則說明磁盤I/O存在問題，考慮提高磁盤I/O讀寫性能。
判斷網絡帶寬是否是瓶頸的方法：判斷網絡帶寬是否是系統運行性能瓶頸的首要條件是網絡帶寬是否會影響系統交易執行性能。例如：減小網絡帶寬，並發用戶數、響應時間與事務通過率等性能指標是否不能接受；或者增加網絡帶寬，並發用戶數、響應時間與事務通過率等性能指標會得到明顯提高。
在實際性能測試中，如果發現始終報連接超時，而實際手工訪問可以正常訪問，可以通過ping應用服務器IP或網關IP，如果出現網絡嚴重延遲或丟包，則說明網絡不穩定，需要檢查網絡。
通過對資源指標四個指標的分析，實際上各個方面都是互相依賴的，不能孤立的單從某個方面進行排查。當一個方面出現性能問題時，往往會引發其他方面的 性能問題，例如，大量的磁盤讀寫勢必消耗CPU和IO資源，而內存的不足會導致頻繁地進行內存頁寫入磁盤、磁盤寫到內存的操作，造成磁盤IO瓶頸，同時， 大量的網絡流量也會造成CPU過載，所以，在分析性能問題時，需要從各個方面進行考慮。
Ø 系統指標分析
並發用戶數：系統能夠支持的用戶數是系統容量的重要標志，並發用戶數用於度量系統在高並發量訪問下，系統的並行處理能力，一般如果系統中存在死鎖、資源爭用，在並發訪問下，由於請求處於隊列等待中，系統響應就會隨着時間變慢。
一般情況下，選用高吞吐量、高數據庫I/O、高商業風險的業務功能進行並發用戶訪問測試。
判斷系統能夠承受的最大並發用戶數，通常以滿足以下條件為准：
1、業務功能操作平均響應時間在合理范圍之內
2、事務成功率在合理范圍之內
3、 系統運行無故障（無異常宕機）
4、系統資源指標使用在合理范圍內
平均響應時間：對於客戶端用戶來說，最直觀的體驗就是訪問該頁面快或者慢，即響應時 間的長短。比如在持續並發性能測試過程中，客戶感知訪問應用很慢，監控到的平均響應時間也逐漸變長，這時就需要先借助於監控到的資源指標，首先排除資源方 面的限制因素，再從應用本身進行定位，如可以采用頁面細分工具（如httpwatch、Loadrunner Anaysis中的頁面組件細分）分析響應比較慢的頁面。
事務成功率、超時出錯率：事務成功率越高，則表明系統處理能力越大；而失敗事務主要由於系統響應慢，導致訪問業務功能超時，或者系統業務功能異常，不能正常訪問等，需要根據事務錯誤提示信息，具體分析。