214      小米MIX

測試指標__性能測試技術體係_性能測試體係_性能測試-阿裏雲

訪問性能測試控製台

1 引言

1.1 編寫目的

本文總結提煉性能測試相關項目實施經驗，規範使用性能測試進行性能測試係統技術指標，規範技術測試結果評價，統一性能測試技術測試質量度量。 應用係統技術質量度量指標範圍廣泛，本文難以涵蓋全部。用常用指標來進行說明，其他未說明指標將在後續測試工作中繼續補充和完善本指標體係。

1.2 適用對象和範圍

本指標適用於使用性能測試進行性能測試項目技術質量評價依據。 預期讀者為測試管理人員、測試實施人員、技術支持人員、項目管理人員等係統技術質量相關人員。

2 係統性能指標

2.1 業務指標

業務指標主要包括並發用戶數、響應時間、處理能力，這三個指標有一定的關係的，具體可參照：《並發用戶數與TPS關係》

2.1.1 交易響應時間

2.1.1.1 定義及解釋

響應時間指用戶從客戶端發起一個請求開始，到客戶端接收到從服務器端返回的響應結束，整個過程所耗費的時間。在性能檢測中一般以測試環境中壓力發起端至服務器返回處理結果的時間為計量，單位一般為秒或毫秒,該時間不同於模擬真實環境的用戶體驗時間。
平均響應時間：指係統穩定運行時間段內，同一交易的平均響應時間。一般而言，交易響應時間均指平均響應時間。
平均響應時間指標值應根據不同的交易分別設定，一般情況下，分為複雜交易響應時間、簡單交易響應時間、特殊交易響應時間。其中，特殊交易響應時間的設定必須明確該交易在響應時間方麵的特殊性。

2.1.1.2 簡稱

Response Time: RT

2.1.1.3 標準

不同行業不同業務可接受的響應時間是不同的，一般情況，對於在線實時交易：

• 互聯網企業：500毫秒以下，例如淘寶業務10毫秒左右。
• 金融企業：1秒以下為佳，部分複雜業務3秒以下。
• 保險企業：3秒以下為佳。
• 製造業：5秒以下為佳。

對於批量交易：

• 時間窗口：不同數據量結果是不一樣的，大數據量的情況下，2小時內完成。

2.1.2 係統處理能力

2.1.2.1 定義及解釋

係統處理能力是指係統在利用係統硬件平台和軟件平台進行信息處理的能力。
係統處理能力通過係統每秒鍾能夠處理的交易數量來評價，交易有兩種理解：一是業務人員角度的一筆業務過程；二是係統角度的一次交易申請和響應過程。前者稱為業務交易過程，後者稱為事務。兩種交易指標都可以評價應用係統的處理能力。一般的建議與係統交易日誌保持一致，以便於統計業務量或者交易量。係統處理能力指標是技術測試活動中重要指標。

2.1.2.2 簡稱

一般情況下，用以下幾個指標來度量：

• HPS（Hits Per Second） ：每秒點擊次數，單位是次/秒。
• TPS（Transaction per Second）：係統每秒處理交易數，單位是筆/秒。
• QPS（Query per Second）：係統每秒處理查詢次數，單位是次/秒。
  對於互聯網業務中，如果某些業務有且僅有一個請求連接，那麼TPS=QPS=HPS，一般情況下用TPS來衡量整個業務流程，用QPS來衡量接口查詢次數，用HPS來表示對服務器點擊請求。

2.1.2.3 標準

無論TPS、QPS、HPS,此指標是衡量係統處理能力非常重要的指標，越大越好，根據經驗，一般情況下：

• 金融行業：1000TPS~9000TPS
• 保險行業：100TPS~1000TPS
• 製造行業：10TPS~50TPS
• 互聯網電子商務：10000TPS~100000TPS,例如天貓5萬TPS
• 互聯網中型網站：100TPS~500TPS
• 互聯網小型網站: 50TPS~100TPS

2.1.3 並發用戶數

2.1.3.1 定義及解釋

並發用戶數指在同一時刻內，登錄係統並進行業務操作的用戶數量。
並發用戶數對於長連接係統來說最大並發用戶數即是係統的並發接入能力。對於短連接係統而言最大並發用戶數並不等於係統的並發接入能力，而是與係統架構、係統處理能力等各種情況相關。
在測試中，采用虛擬用戶來模擬現實中用戶進行業務操作。

2.1.3.2 簡稱

Virtual User: VU

2.1.3.3 標準

一般情況下，性能測試是將係統處理能力容量測出來，而不是測試並發用戶數，除了服務器長連接可能影響並發用戶數外，係統處理能力不受並發用戶數影響，可以用最小的用戶數將係統處理能力容量測試出來，也可以用更多的用戶將係統處理能力容量測試出來。

2.1.4 錯誤率

2.1.4.1 定義及解釋

錯誤率指係統在負載情況下，失敗交易的概率。錯誤率＝(失敗交易數/交易總數)*100%。穩定性較好的係統，其錯誤率應該由超時引起，即為超時率。

2.1.4.2 簡稱

　Failure Ratio: FR

2.1.4.3 標準

不同係統對錯誤率的要求不同，但一般不超出千分之六，即成功率不低於99.4%

2.2 資源指標

2.2.1 CPU

2.2.1.1 定義及解釋

中央處理器是一塊超大規模的集成電路，是一台計算機的運算核心（Core）和控製核心（ Control Unit）。它的功能主要是解釋計算機指令以及處理計算機軟件中的數據。 CPU Load: 係統正在幹活的多少的度量，隊列長度。係統平均負載。

2.2.1.2 簡稱

Central Processing Unit：CPU

2.2.1.3 標準

CPU指標主要指的CPU利用率，包括用戶態(user)、係統態(sys)、等待態(wait)、空閑態(idle)。 CPU 利用率要低於業界警戒值範圍之內，即小於或者等於75%;CPU sys%小於或者等於30%, CPU wait%小於或者等於5%。
單核CPU也需遵循上述指標要求。
CPU Load要小於CPU 核數。

2.2.2 Memory

2.2.2.1 定義及解釋

內存是計算機中重要的部件之一，它是與CPU進行溝通的橋梁。計算機中所有程序的運行都是在內存中進行的，因此內存的性能對計算機的影響非常大。

2.2.2.2 簡稱

Memory就是內存的簡稱。

2.2.2.3 標準

現代的操作係統為了最大利用內存，在內存中存放了緩存，因此內存利用率100%並不代表內存有瓶頸，衡量係統內有有瓶頸主要靠SWAP（與虛擬內存交換）交換空間利用率，一般情況下，SWAP交換空間利用率要低於70%,太多的交換將會引起係統性能低下。

2.2.3 磁盤吞吐量

2.2.3.1 定義及解釋

磁盤吞吐量是指在無磁盤故障的情況下單位時間內通過磁盤的數據量。

2.2.3.2 簡稱

Disk Throughput.

2.2.3.3 標準

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

2.2.4 網絡吞吐量

2.2.4.1 定義及解釋

網絡吞吐量是指在無網絡故障的情況下單位時間內通過的網絡的數據數量。單位為Byte/s。
網絡吞吐量指標用於衡量係統對於網絡設備或鏈路傳輸能力的需求。當網絡吞吐量指標接近網絡設備或鏈路最大傳輸能力時，則需要考慮升級網絡設備。

2.2.4.2 簡稱

Network Throughput

2.2.4.3 標準

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

2.2.5 內核參數

操作係統內核參數主要包括信號量、進程、文件句柄，一般不要超過設置的參數值即可，具體如下:

2.3 中間件指標

2.3.1 定義及解釋

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

2.3.2 標準

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

2.4 數據庫指標

2.4.1 定義及解釋

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

2.4.2 標準

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

2.5 前端指標

2.5.1 定義及解釋

前端指標主要包括頁麵展示和網絡所花的時間，具體如下：

2.5.2 標準

• 頁麵要盡可能小及壓縮。
• 頁麵展示和花費時間越短越好。

2.6 穩定性指標

2.6.1 定義及解釋

最短穩定時間：係統按照最大容量的80%或標準壓力（係統的預期日常壓力）情況下運行，能夠穩定運行的最短時間。
一般來說，對於正常工作日（8小時）運行的係統，至少應該能保證係統穩定運行８小時以上。對於7*24運行的係統，至少應該能夠保證係統穩定運行24小時以上。
如果係統不能穩定的運行，上線後，隨著業務量的增長和長時間運行，將會出現性能下降甚至崩潰的風險。

2.6.2 標準

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

2.7 批量處理指標

2.7.1 定義及解釋

指批量處理程序單位時間內處理的數據數量。一般用每秒處理的數據量來衡量。處理效率是估算批量處理時間窗口最重要的計算指標。
關於批量處理時間窗口，不同係統的批量處理時間窗口在起止時間上可以部分重疊。另外，同一係統內部，也可能存在多個批量處理過程同時進行，其時間窗口相互疊加。
長時間批量處理將會對聯機在線實時交易產生重大的性能影響。

2.7.2 標準

• 在數據量很大的情況下，批處理時間窗口時間越短越好。
• 不能影響實時交易係統性能。

2.8 可擴展性指標

2.8.1 定義及解釋

指應用軟件或操作係統以群集方式部署，增加的硬件資源與增加的處理能力之間的關係。計算公式為：（增加性能/原始性能）/（增加資源/原始資源）*100%。
擴展能力應通過多輪測試獲得擴展指標的變化趨勢。
一般擴展能力你常好的應用係統，擴展指標應是線性或接近線性的，現在很多大規模的分布式係統的擴展能力非常好。

2.8.2 標準

• 理想的擴展能力是資源增加幾倍，性能就提升幾倍。
• 擴展能力至少在70%以上。

2.9 可靠性指標

2.9.1 雙機熱備

對於將雙機熱備作為可靠性保障手段的係統，可衡量的指標如下：

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

2.9.2 集群

對於使用集群方式的係統，主要通過以下方式考量其集群可靠性：

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

2.9.3 備份和恢複

本指標為了驗證係統的備份/恢複機製是否有效可靠，包括係統的備份和恢複、數據庫的備份和恢複、應用的備份和恢複，包括以下測試內容：

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

訪問性能測試控製台

最後更新：2016-05-06 10:44:39

  上一篇： 性能測試技術指南__性能測試技術體係_性能測試體係_性能測試-阿裏雲

  下一篇： 業務模型__性能測試技術體係_性能測試體係_性能測試-阿裏雲