系統性能指標
1.1 交易響應時間
1.1.1 定義及解釋
響應時間指用戶從客戶端發起一個請求開始，到客戶端接收到從服務器端返回的響應結束，整個過程所耗費的時間。在性能檢測中一般以壓力發起端至被壓測服務器返回處理結果的時間為計量，單位一般為秒或毫秒,如果利用PTS發起側優勢+生產環境則無限接近於真實環境的用戶體驗時間了。平均響應時間：指系統穩定運行時間段內，同一交易的平均響應時間。一般而言，交易響應時間均指平均響應時間。平均響應時間指標值應根據不同的交易分別設定，一般情況下，分為復雜交易響應時間、簡單交易響應時間、特殊交易響應時間。其中，特殊交易響應時間的設定必須明確該交易在響應時間方面的特殊性。
1.1.2 簡稱
Response Time: RT
1.1.3 參考標准
不同行業不同業務可接受的響應時間是不同的，一般情況，對於在線實時交易：
- 互聯網企業：500毫秒以下，例如淘寶業務10毫秒左右。
- 金融企業：1秒以下為佳，部分復雜業務3秒以下。
- 保險企業：3秒以下為佳。
- 制造業：5秒以下為佳。
對於批量交易：
- 時間窗口：不同數據量結果是不一樣的，大數據量的情況下，2小時內完成。
1.2 系統處理能力
1.2.1 定義及解釋
系統處理能力是指系統在利用系統硬件平台和軟件平台進行信息處理的能力。系統處理能力通過系統每秒鍾能夠處理的交易數量來評價，交易有兩種理解：一是業務人員角度的一筆業務過程；二是系統角度的一次交易申請和響應過程。前者稱為業務交易過程，后者稱為事務。兩種交易指標都可以評價應用系統的處理能力。一般的建議與系統交易日志保持一致，以便於統計業務量或者交易量。系統處理能力指標是技術測試活動中重要指標。
1.2.2 簡稱
一般情況下，用以下幾個指標來度量：
- HPS（Hits Per Second） ：每秒點擊次數，單位是次/秒。
- TPS（Transaction per Second）：系統每秒處理交易數，單位是筆/秒。
- QPS（Query per Second）：系統每秒處理查詢次數，單位是次/秒。對於互聯網業務中，如果某些業務有且僅有一個請求連接，那么TPS=QPS=HPS，一般情況下用TPS來衡量整個業務流程，用QPS來衡量接口查詢次數，用HPS來表示對服務器點擊請求。
1.2.3 標准
無論TPS、QPS、HPS,此指標是衡量系統處理能力非常重要的指標，越大越好，根據經驗，一般情況下：
- 金融行業：1000TPS~50000TPS，不包括互聯網化的活動
- 保險行業：100TPS~100000TPS，不包括互聯網化的活動
- 制造行業：10TPS~5000TPS
- 互聯網電子商務：10000TPS~1000000TPS
- 互聯網中型網站：1000TPS~50000TPS
- 互聯網小型網站: 500TPS~10000TPS
1.3 並發用戶數
1.3.1 定義及解釋
並發用戶數指在同一時刻內，登錄系統並進行業務操作的用戶數量。並發用戶數對於長連接系統來說最大並發用戶數即是系統的並發接入能力。對於短連接系統而言最大並發用戶數並不等於系統的並發接入能力，而是與系統架構、系統處理能力等各種情況相關。比如系統吞吐能力很強，加上短連接一般都有連接復用，往往並發用戶數大於系統的並發接入連接數。所以對於大部分短連接類型的系統，吞吐量模式（RPS模式,Request Per Second）比較適合，也是阿里的最佳實踐，PTS支持RPS模式的壓測，吞吐量的壓測構建和衡量一步到位。在測試中，采用虛擬用戶來模擬現實中用戶進行業務操作。
1.3.2 簡稱
Virtual User: VU
1.3.3 標准
一般情況下，性能測試是將系統處理能力容量測出來，而不是測試並發用戶數，除了服務器長連接可能影響並發用戶數外，系統處理能力不受並發用戶數影響，可以用最小的用戶數將系統處理能力容量測試出來，也可以用更多的用戶將系統處理能力容量測試出來。
1.4 錯誤率
1.4.1 定義及解釋
錯誤率指系統在負載情況下，失敗交易的概率。錯誤率＝(失敗交易數/交易總數)*100%。穩定性較好的系統，其錯誤率應該由超時引起，即為超時率。
1.4.2 簡稱
Failure Ratio: FR
1.4.3 標准
不同系統對錯誤率的要求不同，但一般不超出千分之六，即成功率不低於99.4%
2 資源指標
2.1 CPU
2.1.1 定義及解釋
中央處理器是一塊超大規模的集成電路，是一台計算機的運算核心（Core）和控制核心（ Control Unit）。它的功能主要是解釋計算機指令以及處理計算機軟件中的數據。CPU Load: 系統正在干活的多少的度量，隊列長度。系統平均負載。
2.1.2 簡稱
Central Processing Unit：CPU
2.1.3 標准
CPU指標主要指的CPU利用率，包括用戶態(user)、系統態(sys)、等待態(wait)、空閑態(idle)。CPU 利用率要低於業界警戒值范圍之內，即小於或者等於75%;CPU sys%小於或者等於30%, CPU wait%小於或者等於5%。單核CPU也需遵循上述指標要求。CPU Load要小於CPU 核數。
2.2 Memory
2.2.1 定義及解釋
內存是計算機中重要的部件之一，它是與CPU進行溝通的橋梁。計算機中所有程序的運行都是在內存中進行的，因此內存的性能對計算機的影響非常大。
2.2.2 簡稱
Memory就是內存的簡稱。
2.2.3 標准
現代的操作系統為了最大利用內存，在內存中存放了緩存，因此內存利用率100%並不代表內存有瓶頸，衡量系統內有有瓶頸主要靠SWAP（與虛擬內存交換）交換空間利用率，一般情況下，SWAP交換空間利用率要低於70%,太多的交換將會引起系統性能低下。
2.3 磁盤吞吐量
2.3.1 定義及解釋
磁盤吞吐量是指在無磁盤故障的情況下單位時間內通過磁盤的數據量。
2.3.2 簡稱
Disk Throughput.
2.3.3 標准
磁盤指標主要有每秒讀寫多少兆，磁盤繁忙率，磁盤隊列數，平均服務時間，平均等待時間，空間利用率。其中磁盤繁忙率是直接反映磁盤是否有瓶頸的的重要依據，一般情況下，磁盤繁忙率要低於70%。
2.4 網絡吞吐量
2.4.1 定義及解釋
網絡吞吐量是指在無網絡故障的情況下單位時間內通過的網絡的數據數量。單位為Byte/s。網絡吞吐量指標用於衡量系統對於網絡設備或鏈路傳輸能力的需求。當網絡吞吐量指標接近網絡設備或鏈路最大傳輸能力時，則需要考慮升級網絡設備。
2.4.2 簡稱
Network Throughput
2.4.3 標准
網絡吞吐量指標主要有每秒有多少兆流量進出，一般情況下不能超過設備或鏈路最大傳輸能力的70%。
2.5 內核參數
操作系統內核參數主要包括信號量、進程、文件句柄，一般不要超過設置的參數值即可，具體如下:
|
一級指標
|
二級指標
|
單位
|
解釋
|
備注
|
|---|---|---|---|---|
| 內核參數 | Maxuprc | 個 | 限制每個用戶的用戶進程的最大數量 | |
| Max_thread_proc | 個 | 定義每個進程允許的最大線程數量 | ||
| Filecache_max | 字節 | 最大可用於cache file I/O的物理內存 | ||
| Ninode | 個 | 內存中 HFS 文件系統打開 i 節點的最大數量 | ||
| Nkthread | 個 | 限制允許同時運行的線程數量 | ||
| Nproc | 個 | 限制允許同時運行的進程數量 | ||
| Nstrpty | 個 | 基於 STREAMS 的偽終端 (pts) 的最大數量 | ||
| Maxdsiz | 字節 | 任何用戶進程的數據段的最大大小（以字節為單位） | ||
| maxdsiz_64bit | 字節 | 任何用戶進程的數據段的最大大小（以字節為單位） | ||
| maxfiles_lim | 個 | 每個進程的文件描述符的最大數目硬限制 | ||
| maxssiz_64bit | 字節 | 任何用戶進程的堆棧的最大大小 | ||
| Maxtsiz | 字節 | 任一用戶進程的文本段的最大大小 | ||
| nflocks | 個 | 文件鎖的最大數量 | ||
| maxtsiz_64bit | 字節 | 任一用戶進程的文本段的最大大小 | ||
| msgmni | 個 | 系統級 System V IPC 消息隊列 (ID) 所允許的最大數量 | ||
| msgtql | 個 | 系統中任意時間的最大 System V IPC 消息數 | ||
| npty | 個 | BSD 偽終端 (pty) 的最大數量 | ||
| nstrtel | 個 | 指定內核可支持傳入 telnet 會話的 telnet 設備文件的數量 | ||
| nswapdev | 個 | 可用於交換的設備的最大數量 | ||
| nswapfs | 個 | 可用於交換的文件系統的最大數量 | ||
| semmni | 個 | System V IPC 系統級信號量標識符的數量 | ||
| semmns | 個 | System V 系統級信號量的數量 | ||
| shmmax | 字節 | System V 共享內存段的最大大小 | ||
| shmmni | 個 | 系統中 System V 共享內存段標識符的數量 | ||
| shmseg | 個 | 每個進程 System V 共享內存段的最大數量 |
3 中間件指標
3.1 定義及解釋
常用的中間件例如Tomcat、Weblogic等指標主要包括JVM, ThreadPool, JDBC,具體如下：
| 一級指標 | 二級指標 | 單位 | 解釋 | 備注 |
|---|---|---|---|---|
| GC | GC頻率 | 每秒多少次 | java虛擬機垃圾部分回收頻率 | |
| Full GC頻率 | 每小時多少次 | java虛擬機垃圾完全回收頻率 | ||
| Full GC平均時長 | 秒 | 用於垃圾完全回收的平均時長 | ||
| Full GC最大時長 | 秒 | 用於垃圾完全回收的最大時長 | ||
| 堆使用率 | 百分比 | 堆使用率 | ||
| ThreadPool | Active Thread Count | 個 | 活動的線程數 | |
| Pending User Request | 個 | 處於排隊的用戶請求個數 | ||
| JDBC | JDBC Active Connection | 個 | JDBC活動連接數 |
3.2 標准
- 當前正在運行的線程數不能超過設定的最大值。一般情況下系統性能較好的情況下，線程數最小值設置50和最大值設置200比較合適。
- 當前運行的JDBC連接數不能超過設定的最大值。一般情況下系統性能較好的情況下，JDBC最小值設置50和最大值設置200比較合適。
- ＧＣ頻率不能頻繁，特別是FULL GC更不能頻繁，一般情況下系統性能較好的情況下，JVM最小堆大小和最大堆大小分別設置1024M比較合適。
4 數據庫指標
4.1 定義及解釋
常用的數據庫例如ＭySQL指標主要包括SQL、吞吐量、緩存命中率、連接數等，具體如下：
| 一級指標 | 二級指標 | 單位 | 解釋 | 備注 |
|---|---|---|---|---|
| SQL | 耗時 | 微秒 | 執行SQL耗時 | |
| 吞吐量 | QPS | 個 | 每秒查詢次數 | |
| TPS | 個 | 每秒事務次數 | ||
| 命中率 | Key Buffer命中率 | 百分之 | 索引緩沖區命中率 | |
| InnoDB Buffer命中率 | 百分之 | InnoDB緩沖區命中率 | ||
| Query Cache命中率 | 百分之 | 查詢緩存命中率 | ||
| Table Cache命中率 | 百分之 | 表緩存命中率 | ||
| Thread Cache命中率 | 百分之 | 線程緩存命中率 | ||
| 鎖 | 等待次數 | 次 | 鎖等待次數 | |
| 等待時間 | 微秒 | 鎖等待時間 |
4.2 標准
- SQL耗時越小越好，一般情況下微秒級別。
- 命中率越高越好，一般情況下不能低於95%。
- 鎖等待次數越低越好，等待時間越短越好。
5 前端指標
5.1 定義及解釋
前端指標主要包括頁面展示和網絡所花的時間，具體如下：
| 一級指標 | 二級指標 | 單位 | 解釋 | 備注 |
|---|---|---|---|---|
| 頁面展示 | 首次顯示時間 | 毫秒 | 在瀏覽器地址欄輸入URL按回車到用戶看到網頁的第一個視覺標志為止 | |
| OnLoad事件時間 | 毫秒 | 瀏覽器觸發onLoad事件的時間，當原始文檔和所有引用的內容完全下載后才會觸發這個事件 | ||
| 完全載入的時間 | 毫秒 | 所有onLoad JavaScript 處理程序執行完畢，所有動態的或延遲加載的內容都通過這些處理程序觸發的時間 | ||
| 頁面數量 | 頁面大小 | KB | 整個頁面大小 | |
| 請求數量 | 次 | 從網站下載資源時所有網絡請求的總數，盡量少 | ||
| 網絡 | DNS時間 | 毫秒 | DNS查找時間 | |
| 連接時間 | 毫秒 | 連接時間就是瀏覽器與Web服務器建立TCP/IP連接的時間 | ||
| 服務器時間 | 毫秒 | 服務器處理時間 | ||
| 傳輸時間 | 毫秒 | 內容傳輸所用時間 | ||
| 等待時間 | 毫秒 | 等待某個資源釋放的時間 |
5.2 標准
- 頁面要盡可能小及壓縮。
- 頁面展示和花費時間越短越好。
6 穩定性指標
6.1 定義及解釋
最短穩定時間：系統按照最大容量的80%或標准壓力（系統的預期日常壓力）情況下運行，能夠穩定運行的最短時間。一般來說，對於正常工作日（8小時）運行的系統，至少應該能保證系統穩定運行８小時以上。對於7*24運行的系統，至少應該能夠保證系統穩定運行24小時以上。如果系統不能穩定的運行，上線后，隨着業務量的增長和長時間運行，將會出現性能下降甚至崩潰的風險。
6.2 標准
- TPS曲線穩定，沒有大幅度的波動。
- 各項資源指標沒有泄露或異常情況。
7 批量處理指標
7.1 定義及解釋
指批量處理程序單位時間內處理的數據數量。一般用每秒處理的數據量來衡量。處理效率是估算批量處理時間窗口最重要的計算指標。關於批量處理時間窗口，不同系統的批量處理時間窗口在起止時間上可以部分重疊。另外，同一系統內部，也可能存在多個批量處理過程同時進行，其時間窗口相互疊加。長時間批量處理將會對聯機在線實時交易產生重大的性能影響。
7.2 標准
- 在數據量很大的情況下，批處理時間窗口時間越短越好。
- 不能影響實時交易系統性能。
8 可擴展性指標
8.1 定義及解釋
指應用軟件或操作系統以群集方式部署，增加的硬件資源與增加的處理能力之間的關系。計算公式為：（增加性能/原始性能）/（增加資源/原始資源）*100%。擴展能力應通過多輪測試獲得擴展指標的變化趨勢。一般擴展能力非常好的應用系統，擴展指標應是線性或接近線性的，現在很多大規模的分布式系統的擴展能力非常好。
8.2 標准
- 理想的擴展能力是資源增加幾倍，性能就提升幾倍。
- 擴展能力至少在70%以上。
9 可靠性指標
9.1 雙機熱備
對於將雙機熱備作為可靠性保障手段的系統，可衡量的指標如下：
- 節點切換是否成功及其消耗時間
- 雙機切換是否有業務中斷
- 節點回切是否成功及其耗時
- 雙機回切是否有業務中斷
- 節點回切過程中的數據丟失量在進行雙機切換的同時，使用壓力發生工具模擬實際業務發生情況，對應用保持一定的性能壓力，保證測試結果符合生產實際情況。
9.2 集群
對於使用集群方式的系統，主要通過以下方式考量其集群可靠性：
- 集群中某個節點出現故障時，系統是否有業務中斷情況出現
- 在集群中新增一個節點時，是否需要重啟系統
- 當故障節點恢復后，加入集群，是否需要重啟系統
- 當故障節點恢復后，加入集群，系統是否有業務中斷情況出現
- 節點切換需要多長時間在驗證集群可靠性的同時，需根據具體情況使用壓力工具模擬實際業務發生相關情況，對應用保持一定的性能壓力，確保測試結果符合生產實際情況。
9.3 備份和恢復
本指標為了驗證系統的備份/恢復機制是否有效可靠，包括系統的備份和恢復、數據庫的備份和恢復、應用的備份和恢復，包括以下測試內容：
- 備份是否成功及其消耗時間
- 備份是否使用腳本自動化完成
- 恢復是否成功及其消耗時間
- 恢復是否使用腳本自動化完成指標體系的運用原則
- 指標項的采用和考察取決於對相應系統的測試目的和測試需求。被測系統不一樣，測試目的不一樣，測試需求也不一樣，考察的指標項也有很大差別。
- 部分系統涉及額外的前端用戶接入能力的，需要考察用戶接入並發能力指標。
- 對於批量處理過程的性能驗證，主要考慮批量處理效率並估算批量處理時間窗口。
- 如測試目標涉及到系統性能容量，測試需求中應根據相關指標項的定義，明確描述性能指標需求。
- 測試指標獲取后，需說明相關的前提條件（如在多少的業務量、系統資源情況等）。