性能測試名額

系統性能名額

1. 交易響應時間

   1. 定義及解釋

      響應時間指使用者從用戶端發起一個請求開始，到用戶端接收到從伺服器端傳回的響應結束，整個過程所耗費的時間。在性能檢測中一般以壓力發起端至被壓測伺服器傳回處理結果的時間為計量，機關一般為秒或毫秒。平均響應時間指系統穩定運作時間段内，同一交易的平均響應時間。一般而言，交易響應時間均指平均響應時間。 平均響應時間名額值應根據不同的交易分别設定，一般情況下，分為複雜交易響應時間、簡單交易響應時間、特殊交易響應時間。其中，特殊交易響應時間的設定必須明确該交易在響應時間方面的特殊性。

   2. 簡稱

      Response Time: RT

   3. 參考标準

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

      • 網際網路企業：500毫秒以下，例如淘寶業務10毫秒左右。
      • 金融企業：1秒以下為佳，部分複雜業務3秒以下。
      • 保險企業：3秒以下為佳。
      • 制造業：5秒以下為佳。
      對于批量交易：
      • 時間視窗：即整個壓測過程的時間，不同資料量則時間不一樣，例如雙11和99大促，資料量級不一樣則時間視窗不同。大資料量的情況下，2小時内可完成壓測。
2. 系統處理能力
   1. 系統處理能力是指系統在利用系統硬體平台和軟體平台進行資訊處理的能力。 系統處理能力通過系統每秒鐘能夠處理的交易數量來評價，交易有兩種了解：一是業務人員角度的一筆業務過程；二是系統角度的一次交易申請和響應過程。前者稱為業務交易過程，後者稱為事務。兩種交易名額都可以評價應用系統的處理能力。一般的建議與系統交易日志保持一緻，以便于統計業務量或者交易量。系統處理能力名額是技術測試活動中重要名額。
   2. 一般情況下，用以下幾個名額來度量：
      • HPS（Hits Per Second） ：每秒點選次數，機關是次/秒。
      • TPS（Transaction per Second）：系統每秒處理交易數，機關是筆/秒。
      • QPS（Query per Second）：系統每秒處理查詢次數，機關是次/秒。 對于網際網路業務中，如果某些業務有且僅有一個請求連接配接，那麼TPS=QPS=HPS，一般情況下用TPS來衡量整個業務流程，用QPS來衡量接口查詢次數，用HPS來表示對伺服器單擊請求。

   3. 标準

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

      • 金融行業：1000TPS~50000TPS，不包括網際網路化的活動
      • 保險行業：100TPS~100000TPS，不包括網際網路化的活動
      • 制造行業：10TPS~5000TPS
      • 網際網路電子商務：10000TPS~1000000TPS
      • 網際網路中型網站：1000TPS~50000TPS
      • 網際網路小型網站：500TPS~10000TPS
3. 并發使用者
   1. 并發使用者數指在同一時刻内，登入系統并進行業務操作的使用者數量。 并發使用者數對于長連接配接系統來說最大并發使用者數即是系統的并發接入能力。對于短連接配接系統而言最大并發使用者數并不等于系統的并發接入能力，而是與系統架構、系統處理能力等各種情況相關。例如系統吞吐能力很強，加上短連接配接一般都有連接配接複用，往往并發使用者數大于系統的并發接入連接配接數。是以對于大部分短連接配接類型的系統，吞吐量模式（RPS模式，Request Per Second）比較适合，也是阿裡的最佳實踐，PTS支援RPS模式的壓測，吞吐量的壓測建構和衡量一步到位。 在測試中，采用虛拟使用者來模拟現實中使用者進行業務操作。
   2. Virtual User: VU
   3. 一般情況下，性能測試是将系統處理能力容量測出來，而不是測試并發使用者數，除了伺服器長連接配接可能影響并發使用者數外，系統處理能力不受并發使用者數影響，可以用最小的使用者數将系統處理能力容量測試出來，也可以用更多的使用者将系統處理能力容量測試出來。
4. 錯誤率
   1. 錯誤率指系統在負載情況下，失敗交易的機率。錯誤率＝（失敗交易數/交易總數）*100%。穩定性較好的系統，其錯誤率應該由逾時引起，即為逾時率。
   2. Virtual Failure Ratio: FR: VU
   3. 不同系統對錯誤率的要求不同，但一般不超出千分之六，即成功率不低于99.4%

資源名額

1. CPU
   1. 中央處理器是一塊超大規模的內建電路，是一台計算機的運算核心（Core）和控制核心（ Control Unit）。它的功能主要是解釋計算機指令以及處理計算機軟體中的資料。 CPU Load: 系統正在幹活的多少的度量，隊列長度。系統平均負載。
   2. Central Processing Unit：CPU
   3. CPU名額主要指的CPU使用率使用率，包括使用者态（user）、系統态（sys）、等待态（wait）、空閑态（idle）。CPU 使用率要低于業界警戒值範圍之内，即小于或者等于75%;CPU sys%小于或者等于30%, CPU wait%小于或者等于5%。單核CPU也需遵循上述名額要求。CPU Load要小于CPU 核數。
2. Memory
   1. 記憶體是計算機中重要的部件之一，它是與CPU進行溝通的橋梁。計算機中所有程式的運作都是在記憶體中進行的，是以記憶體的性能對計算機的影響非常大。
   2. Memory就是記憶體的簡稱。
   3. 現代的作業系統為了最大利用記憶體，在記憶體中存放了緩存，是以記憶體使用率100%并不代表記憶體有瓶頸，衡量系統内有有瓶頸主要靠SWAP（與虛拟記憶體交換）交換空間使用率，一般情況下，SWAP交換空間使用率要低于70%，太多的交換将會引起系統性能低下。
3. 磁盤吞吐量
   1. 磁盤吞吐量是指在無磁盤故障的情況下機關時間内通過磁盤的資料量。
   2. Disk Throughput。
   3. 磁盤名額主要有每秒讀寫多少兆，磁盤繁忙率，磁盤隊列數，平均服務時間，平均等待時間，空間使用率。其中磁盤繁忙率是直接反映磁盤是否有瓶頸的重要依據，一般情況下，磁盤繁忙率要低于70%。
4. 網絡吞吐量
   1. 網絡吞吐量是指在無網絡故障的情況下機關時間内通過的網絡的資料數量。機關為Byte/s。網絡吞吐量名額用于衡量系統對于網絡裝置或鍊路傳輸能力的需求。當網絡吞吐量名額接近網絡裝置或鍊路最大傳輸能力時，則需要考慮更新網絡裝置。
   2. Network Throughput
   3. 網絡吞吐量名額主要有每秒有多少兆流量進出，一般情況下不能超過裝置或鍊路最大傳輸能力的70%。

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 共享記憶體段的最大數量

中間件名額

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活動連接配接數

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

資料庫名額

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

   SQL	耗時	微秒	執行SQL耗時
   吞吐量	QPS		每秒查詢次數
   TPS		每秒事務次數
   命中率	Key Buffer命中率	百分之	索引緩沖區命中率
   InnoDB Buffer命中率		InnoDB緩沖區命中率
   Query Cache命中率		查詢緩存命中率
   Table Cache命中率		表緩存命中率
   Thread Cache命中率		線程緩存命中率
   鎖	等待次數	次	鎖等待次數
   等待時間		鎖等待時間

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

前端名額

1. 前端名額主要包括頁面展示和網絡所花的時間，具體如下：

   頁面展示	首次顯示時間	毫秒	在浏覽器位址欄輸入URL按回車到使用者看到網頁的第一個視覺标志為止
   OnLoad事件時間		浏覽器觸發onLoad事件的時間，當原始文檔和所有引用的内容完全下載下傳後才會觸發這個事件
   完全載入的時間		所有onLoad JavaScript 處理程式執行完畢，所有動态的或延遲加載的内容都通過這些處理程式觸發的時間
   頁面數量	頁面大小	KB	整個頁面大小
   請求數量		從網站下載下傳資源時所有網絡請求的總數，盡量少
   網絡	DNS時間		DNS查找時間
   連接配接時間		連接配接時間就是浏覽器與Web伺服器建立TCP/IP連接配接的時間
   伺服器時間		伺服器處理時間
   傳輸時間		内容傳輸所用時間
   		等待某個資源釋放的時間

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

穩定性名額

1. 最短穩定時間：系統按照最大容量的80%或标準壓力（系統的預期日常壓力）情況下運作，能夠穩定運作的最短時間。 一般來說，對于正常工作日（8小時）運作的系統，至少應該能保證系統穩定運作８小時以上。對于7*24運作的系統，至少應該能夠保證系統穩定運作24小時以上。 如果系統不能穩定的運作，上線後，随着業務量的增長和長時間運作，将會出現性能下降甚至崩潰的風險。
2. • TPS曲線穩定，沒有大幅度的波動。
   • 各項資源名額沒有洩露或異常情況。

批量處理名額

1. 指批量處理程式機關時間内處理的資料數量。一般用每秒處理的資料量來衡量。處理效率是估算批量處理時間視窗最重要的計算名額。 關于批量處理時間視窗，不同系統的批量處理時間視窗在起止時間上可以部分重疊。另外，同一系統内部，也可能存在多個批量處理過程同時進行，其時間視窗互相疊加。 長時間批量處理将會對聯機線上實時交易産生重大的性能影響。
2. • 在資料量很大的情況下，批處理時間視窗時間越短越好。
   • 不能影響實時交易系統性能。

可擴充性名額

1. 指應用軟體或作業系統以群集方式部署，增加的硬體資源與增加的處理能力之間的關系。計算公式為：（增加性能/原始性能）/（增加資源/原始資源）*100%。 擴充能力應通過多輪測試獲得擴充名額的變化趨勢。 一般擴充能力非常好的應用系統，擴充名額應是線性或接近線性的，現在很多大規模的分布式系統的擴充能力非常好。
2. • 理想的擴充能力是資源增加幾倍，性能就提升幾倍。
   • 擴充能力至少在70%以上。

可靠性名額

1. 雙機熱備

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

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

2. 叢集

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

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

3. 備份和恢複

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

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