Locust.io：控制每秒請求參數

Question

我一直試圖在EC2計算優化實例上使用Locust.io加載測試我的API服務器。它提供了一個易於配置的選項，用於設置連續請求等待時間和併發用戶數。從理論上講，RPS = 等待時間X#_users。然而，在測試時，這個規則分解爲極低的閾值#_users（在我的實驗中，大約有1200個用戶）。 hatch_rate的變量，#_of_slaves，包括在分佈式測試設置幾乎沒有對RPS沒有影響。

實驗信息

中的檢測具有C3.4x AWS EC2計算節點（AMI圖像）已經完成了16個vCPU，與通用SSD和30GB的RAM。在測試期間，CPU利用率達到最高峯值的60％（取決於孵化率 - 控制產生的併發進程），平均保持在30％以下。

Locust.io

設置：使用pyzmq，和設置與每個vCPU的核心作爲一個從站。請求主體的單個POST請求設置〜20字節，響應主體〜25字節。請求失敗率：< 1％，平均響應時間爲6ms。

變量：（：100毫秒和max：1000毫秒分鐘）設定爲450ms連續請求之間的時間在一個舒適的30每秒，孵化率和RPS通過改變#_users測量。

的RPS遵循方程預測的高達1000個用戶。增加#_用戶之後，收益遞減，達到約1200用戶的上限。 #_用戶這裏不是自變量，更改等待時間也會影響RPS。但是，將實驗設置更改爲32個核心實例（c3.8x實例）或56個核心（採用分佈式設置）並不會影響RPS。

那麼真的，控制RPS的方法是什麼？有什麼明顯的我在這裏失蹤？

Answer 1

（這裏是蝗蟲的作者之一）

首先，你爲什麼要控制RPS？ Locust背後的核心思想之一是描述用戶行爲，並讓它產生負載（請求在你的情況下）。 Locust旨在回答的問題是：我的應用程序可以支持多少個併發用戶？

我知道這很有誘惑力去追求某個RPS號碼，有時候我也會通過爭取任意RPS號碼來「欺騙」。

但是要回答你的問題，你確定你的蝗蟲不會死在最後？如，他們完成一定數量的請求，然後變成空閒，因爲他們沒有其他要執行的任務？很難說沒有看到測試代碼就會發生什麼。建議對較大的生產準備和我已經運行已經在多個但更小的情況下，大多數現實世界的負載測試

分佈式模式。但是，如果你沒有充分利用CPU，這應該沒有關係。你確定你沒有飽和一個CPU核心嗎？不知道你正在運行什麼操作系統，但如果是Linux，你的負載值是多少？