性能專題：一文搞懂性能測試常見名額

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,具體如下：

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

6. 資料庫名額

常用的資料庫例如ＭySQL名額主要包括SQL、吞吐量、緩存命中率、連接配接數等，具體如下：

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

7. 穩定性名額

最短穩定時間：系統按照最大容量的80%或标準壓力（系統的預期日常壓力）情況下運作，能夠穩定運作的最短時間。

一般來說，對于正常工作日（8小時）運作的系統，至少應該能保證系統穩定運作８小時以上。

對于7*24運作的系統，至少應該能夠保證系統穩定運作24小時以上。如果系統不能穩定的運作，上線後，随着業務量的增長和長時間運作，将會出現性能下降甚至崩潰的風險。

參考标準：

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

8. 可擴充性名額

定義和解釋：是指應用軟體或作業系統以群集方式部署，增加的硬體資源與增加的處理能力之間的關系。

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

擴充能力應通過多輪測試獲得擴充名額的變化趨勢。一般擴充能力非常好的應用系統，擴充名額應是線性或接近線性的，現在很多大規模的分布式系統的擴充能力非常好。

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

9. 可靠性名額

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

• 雙機熱備
• 叢集
• 備份和恢複

9.1 雙機熱備

對于将雙機熱備作為可靠性保障手段的系統，可衡量的名額如下：

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

9.2 叢集

對于使用叢集方式的系統，主要通過以下方式考量其叢集可靠性：

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

9.3 備份和恢複

本名額為了驗證系統的備份/恢複機制是否有效可靠，包括系統的備份和恢複、資料庫的備份和恢複、應用的備份和恢複，包括以下測試内容：

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

其中上述提到的【可擴充名額】和【可靠性名額】，大多數公司在開展性能測試的時候很少會涉及到這些測試點，但這些點從産品整體性能和品質角度來講，又是不得不關注的一些重點，算是給大家提供一些測試思路。

最後，關注公衆号「測試開發技術」背景回複me， 可掃碼添加作者個人微信号，免費領取《靈活性能測試分析與規劃性能測試》《網際網路性能測試案例及經驗分享》。

往期精選

TesterHome創始人思寒：如何從手工測試進階自動化測試？十餘年經驗分享 月薪30K+，高薪？一文搞懂什麼是測試開發！ 聊聊測試（開發）工程師核心競争力 推薦一款簡單易用線上引流測試工具：GoReplay 軟體測試工程師又一大挑戰：大資料測試 一文搞定SonarQube接入C#（.NET）代碼品質分析 你所需要掌握的問題排查知識 RobotFrameWork編寫接口測試及如何斷言 微服務下的契約測試(CDC)解讀

歡迎交流

若對測試開發技術感興趣或者想進階測試開發技術能力的，歡迎加Q群交流：50316345，也歡迎添加筆者微信進行交流：jinjian_762357658