性能測試中關鍵指標的監控與分析

1、軟件性能測試須要監控哪些關鍵指標？

軟件性能測試的目的主要有如下三點：

Ø  評價系統當前性能，判斷系統是否知足預期的性能需求。

Ø  尋找軟件系統可能存在的性能問題，定位性能瓶頸並解決問題。

Ø  斷定軟件系統的性能表現，預見系統負載壓力承受力，在應用部署以前，評估系統性能。

而對於用戶來講，則最關注的是當前系統：

Ø  是否知足上線性能要求？

Ø  系統極限承載如何？

Ø  系統穩定性如何？

       所以，針對以上性能測試的目的以及用戶的關注點，要達到以上目的並回答用戶的關注點，就必須首先執行性能測試並明確須要收集、監控哪些關鍵指標，一般狀況下，性能測試監控指標主要分爲：資源指標和系統指標，以下圖所示，資源指標與硬件資源消耗直接相關，而系統指標則與用戶場景及需求直接相關。

 

 

性能測試監控關鍵指標說明：

Ø  資源指標

CPU使用率：指用戶進程與系統進程消耗的CPU時間百分比，長時間狀況下，通常可接受上限不超過85%。

內存利用率：內存利用率=（1-空閒內存/總內存大小）*100%，通常至少有10%可用內存，內存使用率可接受上限爲85%。

磁盤I/O: 磁盤主要用於存取數據，所以當說到IO操做的時候，就會存在兩種相對應的操做，存數據的時候對應的是寫IO操做，取數據的時候對應的是是讀IO操做，通常使用% Disk Time（磁盤用於讀寫操做所佔用的時間百分比）度量磁盤讀寫性能。

網絡帶寬：通常使用計數器Bytes Total/sec來度量，Bytes Total/sec表示爲發送和接收字節的速率，包括幀字符在內。判斷網絡鏈接速度是不是瓶頸，能夠用該計數器的值和目前網絡的帶寬比較。

Ø  系統指標：

併發用戶數：某一物理時刻同時向系統提交請求的用戶數。

在線用戶數：某段時間內訪問系統的用戶數，這些用戶並不必定同時向系統提交請求。

平均響應時間：系統處理事務的響應時間的平均值。事務的響應時間是從客戶端提交訪問請求到客戶端接收到服務器響應所消耗的時間。對於系統快速響應類頁面，通常響應時間爲3秒左右。

事務成功率：性能測試中，定義事務用於度量一個或者多個業務流程的性能指標，如用戶登陸、保存訂單、提交訂單操做都可定義爲事務，以下圖所示：

 

單位時間內系統能夠成功完成多少個定義的事務，在必定程度上反應了系統的處理能力，通常以事務成功率來度量，計算公式以下所示：

超時錯誤率：主要指事務因爲超時或系統內部其它錯誤致使失敗佔總事務的比率。

2、如何監控關鍵指標？

Ø  資源指標監控

主要針對各服務器系統平臺（Windows、Linux、Unix等）資源使用進行監控。

可使用系統自帶的性能監控工具或者第三方工具進行監控，如Windows系統自帶的「系統性能監視器」，以下圖所示：

 

Linux系統下，free、vmstat、sar、iostat等命令監控內存、CPU、磁盤IO等的使用狀況，以下圖所示：

 

第三方監控工具，如spotlight，spotlight是quest公司開發的一款能夠針對多種系統平臺及數據庫進行監控的可視化工具，以下圖所示：

 

Nmon是IBM提供的監控AIX和Linux系統資源的免費工具，能夠對收集的資源信息經過Excel進行統計分析造成直觀的統計圖，以下圖所示：

 

Ø  系統指標監控

系統指標監控通常經過性能測試工具（如LoadRunner、Jmeter等）以圖形化方式監控，以下圖所示，併發用戶數與平均響應時間關係圖。

 

3、如何分析監控的關鍵指標？

經過第二部分監控收集到性能度量關鍵指標，如何進行分析，並判斷是否存在性能瓶頸呢？如下主要從資源指標與系統指標兩方面進行闡述。

Ø   資源指標分析

判斷CPU是不是瓶頸的方法：通常狀況下CPU滿負荷工做，有時候並不能斷定爲CPU出現瓶頸，好比Linux老是試圖要CPU儘量的繁忙，使得任務的吞吐量最大化，即CPU儘量最大化使用。所以，通常判斷CPU爲瓶頸，主要從兩方面：一是CPU空閒持續爲0，二是運行隊列大於CPU核數（經驗值3-4倍），便可斷定存在瓶頸，對於CPU高消耗主要由什麼引發的，多是應用程序不合理形成，也多是硬件資源不足，須要具體問題具體分析，好比問題SQL語句引發，則須要跟蹤並優化引發CPU使用太高的SQL語句。

判斷內存是不是瓶頸的方法：通常至少有10%可用內存，內存使用率可接受上限爲85%。當空閒內存變小時，系統開始頻繁地調動磁盤頁面文件，空閒內存太小多是內存不足或內存泄漏引發，須要根據系統實際狀況監控分析。

vmstat 命令添加時間參數，能夠按自定義時間間隔和次數動態獲取系統內存等信息，未加任何參數只獲取一次數據信息。

swap：虛擬內存使用狀況

free：空閒的內存

cache：文件緩存

si：內存與磁盤的交互

so：內存與磁盤的交互

bi：讀磁盤

bo：寫磁盤

si和so表示內存交換的頻繁程度，若是數值長期很大，表示內存不夠。

判斷磁盤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、高商業風險的業務功能進行併發用戶訪問測試。

判斷系統可以承受的最大併發用戶數，一般以知足如下條件爲準：

一、業務功能操做平均響應時間在合理範圍以內

二、事務成功率在合理範圍以內

三、 系統運行無端障（無異常宕機）

四、系統資源指標使用在合理範圍內

平均響應時間：對於客戶端用戶來講，最直觀的體驗就是訪問該頁面快或者慢，即響應時間的長短。好比在持續併發性能測試過程當中，客戶感知訪問應用很慢，監控到的平均響應時間也逐漸變長，這時就須要先借助於監控到的資源指標，首先排除資源方面的限制因素，再從應用自己進行定位，如能夠採用頁面細分工具（如httpwatch、Loadrunner Anaysis中的頁面組件細分）分析響應比較慢的頁面。

事務成功率、超時出錯率：事務成功率越高，則代表系統處理能力越大；而失敗事務主要因爲系統響應慢，致使訪問業務功能超時，或者系統業務功能異常，不能正常訪問等，須要根據事務錯誤提示信息，具體分析。

綜上所述，軟件性能測試是執行、監控—〉分析—〉調優不斷進行的過程，即監控是爲分析提供更多的參考數據，分析是爲了進行調優，調優是解決當前系統存在的性能瓶頸，爲用戶提供更好、更快的客戶體驗。因爲分析、調優須要根據具體問題進行具體分析，本文未作過多說明，只對通用的關鍵指標進行監控分析，建議在實際工做中可從資源指標與系統指標兩個方面，層層檢測、步步排查，性能問題就無處藏身，一旦找到出現問題的緣由，性能問題也就迎刃而解！