Performance Testing Service：壓力模型

虛擬使用者模式

從虛擬使用者角度，虛擬使用者數為同時線上的使用者數。

• 應用情境

  如果您需要從用戶端的角度出發，瞭解業務系統各節點能同時承載的線上使用者數，可以使用該模式設定目標虛擬使用者。

• 使用說明

  • 虛擬使用者模式下，您需要指定全情境的最大虛擬使用者數，再設定各業務會話的虛擬使用者權重。

  • 業務會話內各API的響應速度不同（表現為回應時間不同），所以單位時間內API的虛擬使用者數也會不同。API響應速度越快，單位時間內累積在API上的虛擬使用者數越少。

    假設，目前共有100個虛擬使用者需要操作某個事務（即業務會話）。該業務會話中有2個API，API 1的響應速度快而API 2響應速度慢。則更多的虛擬使用者將會等待在API 2上，API 2則需要更多的線程資源來處理更多的虛擬使用者請求。

RPS模式

RPS（Requests Per Second）是指每秒請求數。

• 應用情境

  RPS模式即輸送量模式，通過設定每秒發出的請求數，協助您從服務端的角度出發，直接衡量系統的吞吐能力，免去從虛擬使用者到RPS的繁瑣轉化，可快速實現壓測。

• 使用說明

  • API介面（如電商加購物車、下單等）主要用TPS（Transaction Per Second, 每秒事務數）來衡量系統的吞吐能力，選擇該模式可以直接按照預期的TPS設定RPS。如果希望檢驗“下單”介面是否能達到500 TPS的預期，那麼設定RPS為500，每秒發送500個請求，可檢驗系統的吞吐能力。

  • 該模式下，請求無法及時響應，可能會導致施壓端產生較高的虛擬使用者數，異常情況請及時停止。

  • 該模式僅支援非自動遞增進行壓測，即您需在壓測過程中手工調速。具體操作，請參見調速。

  • 同一鏈路中，後一個API的RPS值需小於等於前一個API的RPS值。

    基於您的實際業務考慮，一般正常業務鏈路轉化模型應該為漏鬥形狀。例如，您的正常業務鏈路為：查看首頁-查看商品詳情-加入購物車-下單-付款。那麼通常情況下，查看首頁的使用者數會比查看商品詳情的使用者數多，查看商品詳情的使用者數也會比加入購物車的使用者數多，以此類推，所以後一個API的RPS值需小於前一個API的值，這樣就比較符合漏鬥模型。

配置量級及資料

設定好壓測模式後，您還需要在壓力量級配置地區設定最大虛擬使用者權重與起始百分比。

壓測數值

每個API可以視為業務系統的一個節點，處理能力不同導致可承載的業務量也不一致。虛擬使用者模式與RPS模式施壓的方式不同，故壓測數值上的設定也會不同。