性能專題：一文搞懂性能測試常見指標

1. 前言

上週，對性能測試系列專題，在公號內發表了第一篇介紹：【性能系列連載一】開篇：性能測試不可不知的「乾貨」，但反響貌似並不太好，但既然此前已答應了部分讀者要連載分享性能這塊的知識，含着淚也得繼續寫。

性能測試的基礎：就是在確保功能實現正確的前提下，經過合適的性能測試加壓方式和策略，並收集考察服務端應用程序的各項性能指標，以及服務器硬件資源的使用狀況，來評估是否存在性能問題隱患。

那今天做爲性能測試系列的第二篇，主要會爲你們介紹在服務端性能測試中，常見的性能指標有哪些。

2. 性能指標分類

從性能測試分析度量的度角來看，能夠從以下幾個維度來收集考察各項性能指標：

• 系統性能指標
• 資源性能指標
• 中間件指標
• 數據庫指標
• 穩定性指標
• 可擴展性指標
• 可靠性指標

下面將從如上這幾個維度，分別從各自維度常見指標，以及指標含義、指標行業參考標準等方面進行介紹。

3. 系統性能指標

系統性能指標，常見的可從以下幾類進行參考：

• 響應時間
• 系統處理能力
• 吞吐量
• 併發用戶數
• 錯誤率

3.1 響應時間

定義和解釋：響應時間，簡稱RT。是指系統對請求做出響應的時間，能夠理解爲是指用戶從客戶端發起一個請求開始，到客戶端接收到從服務器端返回的響應結束，整個過程所耗費的時間。直觀上看，這個指標與人對軟件性能的主觀感覺是很是一致的，由於它完整地記錄了整個計算機系統處理請求的時間。

在性能檢測中通常以壓力發起端至被壓測服務器返回處理結果的時間爲計量，單位通常爲秒或毫秒，因爲一個系統一般會提供許多功能，而不一樣功能的處理邏輯也千差萬別，於是不一樣功能的響應時間也不盡相同，甚至同一功能在不一樣輸入數據的狀況下響應時間也不相同。因此，在討論一個系統的響應時間時，一般是指該系統全部功能的平均時間或者全部功能的最大響應時間。

行業參考標準：

不一樣行業不一樣業務可接受的響應時間是不一樣的，通常狀況，對於在線實時交易：

• 互聯網企業：500毫秒如下，例如淘寶業務10毫秒左右。
• 金融企業：1秒如下爲佳，部分複雜業務3秒如下。
• 保險企業：3秒如下爲佳。
• 製造業：5秒如下爲佳。
• 時間窗口：不一樣數據量結果是不同的，大數據量的狀況下，2小時內完成。

須要指出的是，響應時間的絕對值並不能直接反映軟件的性能的高低，軟件性能的高低實際上取決於用戶對該響應時間的接受程度。

3.2 系統處理能力

定義和解釋：系統處理能力是指系統在利用系統硬件平臺和軟件平臺進行信息處理的能力。系統處理能力經過系統每秒鐘可以處理的交易數量來評價，交易有兩種理解：一是業務人員角度的一筆業務過程；二是系統角度的一次交易申請和響應過程。前者稱爲業務交易過程，後者稱爲事務。兩種交易指標均可以評價應用系統的處理能力。

通常狀況下，系統處理能力又用如下幾個指標來度量：

• HPS（Hits Per Second） ：每秒點擊次數，單位是次/秒。
• TPS（Transaction per Second）：系統每秒處理交易數，單位是筆/秒。
• QPS（Query per Second）：系統每秒處理查詢次數，單位是次/秒。

對於互聯網業務中，若是某些業務有且僅有一個請求鏈接，那麼TPS=QPS=HPS，通常狀況下用TPS來衡量整個業務流程，用QPS來衡量接口查詢次數，用HPS來表示對服務器點擊請求。

行業參考標準：

不管TPS、QPS、HPS，此指標是衡量系統處理能力很是重要的指標，越大越好，根據經驗，通常狀況下：

• 金融行業：1000TPS~50000TPS，不包括互聯網化的活動
• 保險行業：100TPS~100000TPS，不包括互聯網化的活動
• 製造行業：10TPS~5000TPS
• 互聯網電子商務：10000TPS~1000000TPS
• 互聯網中型網站：1000TPS~50000TPS
• 互聯網小型網站: 500TPS~10000TPS

3.3 吞吐量

定義和解釋：吞吐量是指系統在單位時間內處理請求的數量。

對於單用戶的系統，響應時間能夠很好地度量系統的性能，但對於併發系統，一般須要用吞吐量做爲性能指標。

而對於一個多用戶的系統，若是隻有一個用戶使用時系統的平均響應時間是t，當有你n個用戶使用時，每一個用戶看到的響應時間一般並非n×t，而每每比n×t小不少（固然，在某些特殊狀況下也可能比n×t大，甚至大不少）。通常而言，吞吐量是一個比較通用的指標，兩個具備不一樣用戶數和用戶使用模式的系統，若是其最大吞吐量基本一致，則能夠判斷兩個系統的處理能力基本一致。

3.4 併發用戶數

定義和解釋：併發用戶數指在同一時刻內，登陸系統並進行業務操做的用戶數量。

併發用戶數對於長鏈接系統來講最大併發用戶數便是系統的併發接入能力。對於短鏈接系統而言最大併發用戶數並不等於系統的併發接入能力，而是與系統架構、系統處理能力等各類狀況相關。

與吞吐量相比，併發用戶數是一個更直觀但也更籠統的性能指標。實際上，併發用戶數是一個很是不許確的指標，由於用戶不一樣的使用模式會致使不一樣用戶在單位時間發出不一樣數量的請求。

3.5  錯誤率

定義和解釋：錯誤率簡稱FR，指系統在負載狀況下，失敗交易的機率。錯誤率＝(失敗交易數/交易總數)*100%。

行業參考標準：

不一樣系統對錯誤率的要求不一樣，但通常不超出千分之六，即成功率不低於99.4%

4. 資源性能指標

資源性能指標，常見的可從以下幾類進行參考：

• CPU
• 內存
• 磁盤吐吞量
• 網絡吐吞量

4.1  CPU

定義和解釋：CPU又稱爲中央處理器，是一塊超大規模的集成電路，是一臺計算機的運算核心（Core）和控制核心（ Control Unit）。它的功能主要是解釋計算機指令以及處理計算機軟件中的數據。

行業參考標準：

CPU指標主要指的CPU利用率，包括用戶態(user)、系統態(sys)、等待態(wait)、空閒態(idle)。

• CPU 利用率要低於業界警惕值範圍以內，即小於或者等於75%;
• CPU sys%小於或者等於30%;
• CPU wait%小於或者等於5%；

4.2  內存

定義和解釋：內存是計算機中重要的部件之一，它是與CPU進行溝通的橋樑。計算機中全部程序的運行都是在內存中進行的，所以內存的性能對計算機的影響很是大。

行業參考標準：

如今的操做系統爲了最大利用內存，在內存中存放了緩存，所以內存利用率100%並不表明內存有瓶頸，衡量系統內存是否有瓶頸主要靠SWAP（與虛擬內存交換）交換空間利用率，通常狀況下，SWAP交換空間利用率要低於70%,太多的交換將會引發系統性能低下。

4.3  磁盤吐吞量

定義和解釋：磁盤吞吐量簡稱爲Disk Throughput，是指在無磁盤故障的狀況下單位時間內經過磁盤的數據量。

行業參考標準：

磁盤指標主要有每秒讀寫多少兆，磁盤繁忙率，磁盤隊列數，平均服務時間，平均等待時間，空間利用率。其中磁盤繁忙率是直接反映磁盤是否有瓶頸的的重要依據，通常狀況下，磁盤繁忙率要低於70%。

4.4  網絡吐吞量

定義和解釋：網絡吞吐量簡稱爲Network Throughput，是指在無網絡故障的狀況下單位時間內經過的網絡的數據數量。單位爲Byte/s。網絡吞吐量指標用於衡量系統對於網絡設備或鏈路傳輸能力的需求。當網絡吞吐量指標接近網絡設備或鏈路最大傳輸能力時，則須要考慮升級網絡設備。

行業參考標準：

網絡吞吐量指標主要有每秒有多少兆流量進出，通常狀況下不能超過設備或鏈路最大傳輸能力的70%。

5. 中間件指標

經常使用的中間件例如Tomcat、Weblogic等指標主要包括JVM, ThreadPool, JDBC,具體以下：

一級指標	二級指標	單位	解釋
GC	GC頻率	每秒多少次	java虛擬機垃圾部分回收頻率
GC	Full GC頻率	每小時多少次	java虛擬機垃圾徹底回收頻率
GC	Full GC平均時長	秒	用於垃圾徹底回收的平均時長
GC	Full GC最大時長	秒	用於垃圾徹底回收的最大時長
GC	堆使用率	百分比	堆使用率
ThreadPool	Active Thread Count	個	活動的線程數
ThreadPool	Pending User Request	個	處於排隊的用戶請求個數
JDBC	JDBC Active Connection	個	JDBC活動鏈接數

 

行業參考標準：

• 當前正在運行的線程數不能超過設定的最大值。通常狀況下系統性能較好的狀況下，線程數最小值設置50和最大值設置200比較合適。
• 當前運行的JDBC鏈接數不能超過設定的最大值。通常狀況下系統性能較好的狀況下，JDBC最小值設置50和最大值設置200比較合適。
• ＧＣ頻率不能頻繁，特別是FULL GC更不能頻繁，通常狀況下系統性能較好的狀況下，JVM最小堆大小和最大堆大小分別設置1024M比較合適。

6. 數據庫指標

經常使用的數據庫例如ＭySQL指標主要包括SQL、吞吐量、緩存命中率、鏈接數等，具體以下：

一級指標	二級指標	單位	解釋
SQL	耗時	微秒	執行SQL耗時
吞吐量	QPS	個	每秒查詢次數
吞吐量	TPS	個	每秒事務次數
命中率	Key Buffer命中率	百分之	索引緩衝區命中率
命中率	InnoDB Buffer命中率	百分比	InnoDB緩衝區命中率
命中率	Query Cache命中率	百分比	查詢緩存命中率
命中率	Table Cache命中率	百分比	表緩存命中率數
命中率	Thread Cache命中率	百分比	線程緩存命中率
鎖	等待次數	次	鎖等待次數
鎖	等待時間	微秒	鎖等待時間

行業參考標準：

• SQL耗時越小越好，通常狀況下微秒級別。
• 命中率越高越好，通常狀況下不能低於95%。
• 鎖等待次數越低越好，等待時間越短越好。

7. 穩定性指標

最短穩定時間：系統按照最大容量的80%或標準壓力（系統的預期平常壓力）狀況下運行，可以穩定運行的最短期。

通常來講，對於正常工做日（8小時）運行的系統，至少應該能保證系統穩定運行８小時以上。

對於7*24運行的系統，至少應該可以保證系統穩定運行24小時以上。若是系統不能穩定的運行，上線後，隨着業務量的增加和長時間運行，將會出現性能降低甚至崩潰的風險。

參考標準：

• TPS曲線穩定，沒有大幅度的波動。
• 各項資源指標沒有泄露或異常狀況。

8. 可擴展性指標

定義和解釋：是指應用軟件或操做系統以羣集方式部署，增長的硬件資源與增長的處理能力之間的關係。

計算公式爲：（增長性能/原始性能）/（增長資源/原始資源）*100%。

擴展能力應經過多輪測試得到擴展指標的變化趨勢。通常擴展能力很是好的應用系統，擴展指標應是線性或接近線性的，如今不少大規模的分佈式系統的擴展能力很是好。

參考標準：

理想的擴展能力是資源增長几倍，性能就提高几倍。擴展能力至少在70%以上。

9. 可靠性指標

對於服務端性能測試，從系統可靠性指標度量分析時，常見從三類來入手：

• 雙機熱備
• 集羣
• 備份和恢復

9.1 雙機熱備

對於將雙機熱備做爲可靠性保障手段的系統，可衡量的指標以下：

• 節點切換是否成功及其消耗時間。
• 雙機切換是否有業務中斷。
• 節點回切是否成功及其耗時。
• 雙機回切是否有業務中斷。
• 節點回切過程當中的數據丟失量在進行雙機切換的同時，使用壓力發生工具模擬實際業務發生狀況，對應用保持必定的性能壓力，保證測試結果符合生產實際狀況。

9.2 集羣

對於使用集羣方式的系統，主要經過如下方式考量其集羣可靠性：

• 集羣中某個節點出現故障時，系統是否有業務中斷狀況出現
• 在集羣中新增一個節點時，是否須要重啓系統
• 當故障節點恢復後，加入集羣，是否須要重啓系統
• 當故障節點恢復後，加入集羣，系統是否有業務中斷狀況出現
• 節點切換須要多長時間在驗證集羣可靠性的同時，需根據具體狀況使用壓力工具模擬實際業務發生相關狀況，對應用保持必定的性能壓力，確保測試結果符合生產實際狀況。

9.3 備份和恢復

本指標爲了驗證系統的備份/恢復機制是否有效可靠，包括系統的備份和恢復、數據庫的備份和恢復、應用的備份和恢復，包括如下測試內容：

• 備份是否成功及其消耗時間。
• 備份是否使用腳本自動化完成。
• 恢復是否成功及其消耗時間。
• 恢復是否使用腳本自動化完成指標體系的運用原則。
• 指標項的採用和考察取決於對相應系統的測試目的和測試需求。被測系統不同，測試目的不同，測試需求也不同，考察的指標項也有很大差異。
• 部分系統涉及額外的前端用戶接入能力的，須要考察用戶接入併發能力指標。
• 對於批量處理過程的性能驗證，主要考慮批量處理效率並估算批量處理時間窗口。
• 如測試目標涉及到系統性能容量，測試需求中應根據相關指標項的定義，明確描述性能指標需求。
• 測試指標獲取後，需說明相關的前提條件（如在多少的業務量、系統資源狀況等）。

其中上述提到的【可擴展指標】和【可靠性指標】，大多數公司在開展性能測試的時候不多會涉及到這些測試點，但這些點從產品總體性能和質量角度來說，又是不得不關注的一些重點，算是給你們提供一些測試思路。

 

最後，關注公衆號「測試開發技術」，並後臺回覆me， 可掃碼添加做者我的微信號，免費領取《敏捷性能測試分析與規劃性能測試》《互聯網性能測試案例及經驗分享》。

點擊可閱讀原文：

更多幹貨，請掃描關注【測試開發技術】