「 性能測驗技術筆記系列（一）」之性能指標行業參考｜收藏版

性能測驗技術筆記系列（一）之性能指標行業參考｜收藏版

大多數測驗人員在談到性能測驗時，往往會倍感壓力，對于我來說更是如此，想做好性能測驗需要龐大的知識體系，不斷實踐所總結的經驗教訓更是彌足珍貴，而且每個人對性能測驗的理解都有獨到的地方，此次逐步揭開性能測驗得神秘面紗，結合課堂學習及自身消化理解后的，歸納了一些性能測驗的基礎知識，希望對大家理解性能測驗有所幫助，

性能測驗的基礎

就是在確保功能實作正確的前提下，通過合適的性能測驗加壓方式和策略，并收集考察服務端應用程式的各項性能指標，以及服務器硬體資源的使用情況，來評估是否存在性能問題隱患，

性能指標分類

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

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

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

系統性能指標

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

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

回應時間

定義和解釋： 回應時間，簡稱RT，是指系統對請求作出回應的時間，可以理解為是指用戶從客戶端發起一個請求開始，到客戶端接收到從服務器端回傳的回應結束，整個程序所耗費的時間，直觀上看，這個指標與人對軟體性能的主觀感受是非常一致的，因為它完整地記錄了整個計算機系統處理請求的時間，

在性能檢測中一般以壓力發起端至被壓測服務器回傳處理結果的時間為計量，單位一般為秒或毫秒，由于一個系統通常會提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的回應時間也不盡相同，甚至同一功能在不同輸入資料的情況下回應時間也不相同，所以，在討論一個系統的回應時間時，通常是指該系統所有功能的平均時間或者所有功能的最大回應時間，

行業參考標準： 不同行業不同業務可接受的回應時間是不同的，一般情況，對于在線實時交易：

• 互聯網企業：500毫秒以下，例如淘寶業務10毫秒左右，
• 金融企業：1秒以下為佳，部分復雜業務3秒以下，
• 保險企業：3秒以下為佳，
• 制造業：5秒以下為佳，
• 時間視窗：不同資料量結果是不一樣的，大資料量的情況下，2小時內完成，
• 互聯網企業：500毫秒以下，例如淘寶業務10毫秒左右，
• 金融企業：1秒以下為佳，部分復雜業務3秒以下，
• 保險企業：3秒以下為佳，
• 制造業：5秒以下為佳，
• 時間視窗：不同資料量結果是不一樣的，大資料量的情況下，2小時內完成，

需要指出的是，回應時間的絕對值并不能直接反映軟體的性能的高低，軟體性能的高低實際上取決于用戶對該回應時間的接受程度，

系統處理能力

定義和解釋： 系統處理能力是指系統在利用系統硬體平臺和軟體平臺進行資訊處理的能力，系統處理能力通過系統每秒鐘能夠處理的交易數量來評價，交易有兩種理解：一是業務人員角度的一筆業務程序；二是系統角度的一次交易申請和回應程序，前者稱為業務交易程序，后者稱為事務，兩種交易指標都可以評價應用系統的處理能力，

一般情況下，系統處理能力又用以下幾個指標來度量：

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

對于互聯網業務中，如果某些業務有且僅有一個請求連接，那么TPS=QPS=HPS，一般情況下用TPS來衡量整個業務流程，用QPS來衡量介面查詢次數，用HPS來表示對服務器點擊請求，

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

吞吐量

定義和解釋： 吞吐量是指系統在單位時間內處理請求的數量，對于單用戶的系統，回應時間可以很好地度量系統的性能，但對于并發系統，通常需要用吞吐量作為性能指標，

而對于一個多用戶的系統，如果只有一個用戶使用時系統的平均回應時間是t，當有你n個用戶使用時，每個用戶看到的回應時間通常并不是n×t，而往往比n×t小很多（當然，在某些特殊情況下也可能比n×t大，甚至大很多），一般而言，吞吐量是一個比較通用的指標，兩個具有不同用戶數和用戶使用模式的系統，如果其最大吞吐量基本一致，則可以判斷兩個系統的處理能力基本一致，

并發用戶數

定義和解釋： 并發用戶數指在同一時刻內，登錄系統并進行業務操作的用戶數量，

并發用戶數對于長連接系統來說最大并發用戶數即是系統的并發接入能力，對于短連接系統而言最大并發用戶數并不等于系統的并發接入能力，而是與系統架構、系統處理能力等各種情況相關，

與吞吐量相比，并發用戶數是一個更直觀但也更籠統的性能指標，實際上，并發用戶數是一個非常不準確的指標，因為用戶不同的使用模式會導致不同用戶在單位時間發出不同數量的請求，

錯誤率

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

行業參考標準：

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

資源性能指標

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

• CPU
• 記憶體
• 磁盤吐吞量
• 網路吐吞量

CPU

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

行業參考標準：

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

• CPU 利用率要低于業界警戒值范圍之內，即小于或者等于75%;
• CPU sys%小于或者等于30%;
• CPU wait%小于或者等于5%；

記憶體

定義和解釋： 記憶體是計算機中重要的部件之一，它是與CPU進行溝通的橋梁，計算機中所有程式的運行都是在記憶體中進行的，因此記憶體的性能對計算機的影響非常大，

行業參考標準：

現在的作業系統為了最大利用記憶體，在記憶體中存放了快取，因此記憶體利用率100%并不代表記憶體有瓶頸，衡量系統記憶體是否有瓶頸主要靠SWAP（與虛擬記憶體交換）交換空間利用率，一般情況下，SWAP交換空間利用率要低于70%,太多的交換將會引起系統性能低下，

磁盤吐吞量

定義和解釋： 磁盤吞吐量簡稱為Disk Throughput，是指在無磁盤故障的情況下單位時間內通過磁盤的資料量，

行業參考標準：

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

網路吐吞量

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

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

中間件指標

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

行業參考標準：

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

資料庫指標

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

行業參考標準：

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

穩定性指標

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

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

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

參考標準：

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

可擴展性指標

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

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

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

參考標準：

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

可靠性指標

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

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

雙機熱備

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

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

集群

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

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

備份和恢復

本指標為了驗證系統的備份/恢復機制是否有效可靠，包括系統的備份和恢復、資料庫的備份和恢復、應用的備份和恢復，包括以下測驗內容：

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

性能測驗場景設計

場景分類

• 手工場景

手工場景可以為同一個組中的不同用戶分配不同的腳本，負載生成器，

• 目標場景

面向目標場景，即首先的定義需要測驗達到的目標，然后loadrunner會自動根據這一目標創建場景，

場景設計策略

• 快增長

使用場合：比如說秒殺功能，

問題： loadrunner場景中的加載方式：simultaneously，即同時加載，和Initialize中的

一次性初始化所有的vuser用戶的選項，兩者有什么區別嗎？

• 慢增長

使用場合：單個場景，比如打開某個頁面，介面，登錄等操作，

• 用戶數執行完場景停止場景

用戶停止場景即用戶執行完場景完后，退出當前的場景的操作，

問題： 一般情況來說，用戶停止場景的方式，是與用戶加載的方式一樣適合還是一次性全部退出場景適合呢？

問題： 用戶場景的執行時間：可以不可以這樣理解，用戶場景的整體執行時間等于：

用戶加載時間+用戶執行時間+用戶退出場景的時間？

場景適用場合

• 單場景

例如：打開某個頁面操作，用戶登錄等，

• 混合場景

混合場景，即多個業務組成的場景，比如BBS論壇發帖，有用戶登錄，發帖，回帖的業務，這些業務可以組成一個混合的場景，在運行場景時，可以指定多少vuser去執行某一個單個業務的操作，

問題： 在混合場景中，針對了某個單業務進行了檢查點的設定，例如BBS論壇的發帖檢查點，當虛擬用戶數變多時，其整個發帖的事物回應時間明顯變慢，是不是增加了檢查點后，在多虛擬用戶執行場景時，會影響到其事務的回應時間呢？或者說檢查點不適合在混合場景中多次添加？

壓力機

• 壓力機定義

壓力機顧名思義就是增加壓力的機器，即負載機，在性能測驗程序中，可以指定多個加壓機對其進行加壓，

• 添加負載機步驟

1、保證聯合的機器上裝了LRagent，并啟用了，（狀態欄會有一個小衛星）

2、本地系統的服務RPC服務開啟，改為自動，

3、請從你的Controller的機子上登錄要聯合的機子，

4、關閉防火墻+殺毒+360等，擁有權限，必須保證負載機器在同一個網段內，保持網路可以相互通信，

參考資料

性能測驗的內容到這里啦！如有需要了解軟體測驗相關的其他內容，可到「 [主頁]」進行查看學習~

同時，有不理解或有誤的地方也歡迎評論區留言大家一起吹牛聊天交流技術??，

• ??如果這篇文章對你有用，記得點個贊????加個關注支持我一下~
• ??我們下期見！??????

??推薦閱讀：

??軟體測驗人員必讀的經典書籍（附電子書），前阿里大佬給我推薦...

??一文了解MySQL性能測驗及調優中的死鎖處理方法，你還看不明白？

??阿里大牛純手碼數十萬字，自動化測驗成神之路電子版教程已問世，開放下載

標籤：其他

上一篇：Web前端安全之安全編碼原則

下一篇：已從事軟體測驗1年，依舊只會功能測驗，我該如何擺脫危機感？