本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

負載測試類型

下列測試類型基於本指南前面列出的基本問題。

我的應用程式可以承受多少負載？

在設定測試以確定應用程式可以承受的負載時，先決定是否要以每秒請求數 (請求/秒)、回應時間 (秒) 或並行使用者數來衡量。對於任何一種情況，定義測試應用程式的哪一部分。

定義目標系統的效能和錯誤率的可接受閾值。對於某些系統，您可能不關心回應時間，只要成功處理事件即可。對於許多應用程式 (例如具有使用者互動的應用程式)，定義最終使用者可以接受的限制。

逐步執行測試通常很有用。每個步驟都會增加負載，直到達到定義的閾值。對於重複測試，您可以從先前的測試中學習並改進您的步驟，以在測試中執行較少的步驟並仍然取得有效的結果。

我的應用程式是否可以處理 X 負載？

與先前的測試類似，此測試中的負載可以定義為請求/秒或並行使用者，具體取決於您正在測試的應用程式的性質。此測試是前一個測試的簡化版本。在此處，必須提交特定的工作負載，且系統應能夠進行處理。選擇支援指定所需負載量的測試工具非常重要。

執行測試的時間也可能相關。有些影響只有在測試執行較長時間後才能觀察到。例如，背壓可能會導致佇列過載。如果您想要複寫生產系統並得出有效的結論，則執行測試所需的時間可能會影響測試系統的規模調整。

我的應用程式是否自動縱向擴展和縮減？

彈性是雲端的關鍵賣點，也是降低成本的關鍵來源。測試您的應用程式是否可以正確擴展，以便您可以自信地從彈性中受益，應成為您的雲端之旅的一部分。

需要確定用於縱向擴展和縮減規模的關鍵指標。通常，這是目標系統的 CPU 負載。建立 CPU 負載的端點可以用作目標。

由於此測試不需要代表性，因此您可以從定位沒有副作用的端點中受益。您也不希望啟動一個流程來保存可能累積的資料，或啟動後續程序並導致不必要的成本或阻止負載。

分步執行測試，逐漸增加負載。間隔應足夠長，以便在每個步驟中，指標都能夠啟動擴展。例如，如果您規定 CPU 負載在 5 分鐘內應高於 70%，則您的步驟應長於 5 分鐘，以便為啟動和執行擴展事件提供時間。您還希望看到擴展是否有效並修復了您建立的負載情況。

請考慮使用不只一部伺服器開始擴展測試。在小型環境中，縱向擴展可能會很慢，且需要多個週期來應對負載。EC2 Auto Scaling 叢集的大小只能增加一倍。這意味著，如果您從一部伺服器開始並開始負載測試，則最大的第一個擴展事件只能是兩部伺服器。如果產生的負載需要三部伺服器，您將需要兩個擴展事件，這可能需要 20 分鐘或更長時間。

監控縱向擴展事件所需的觸發條件以及擴展是否適合實際負載。

如果您已實作縮減規模事件，也可以逐步進行測試。監控縮減規模是否適用且適合現有負載，並確認它不會再次立即啟動縱向擴展。

在持續高負載的情況下，我的應用程式行為是否會隨著時間的推移而降級？

有些影響只有在長時間產生負載時才能觀察到。最重要的影響之一是背壓。這意味著當系統速度太慢而無法以請求數量到來的速度處理請求時，用戶端系統的效能將會降級。

如果慢速系統是負載目標，則更容易觀察到這一點。在更複雜的設定中，只有當負載測試的影響傳播時，您才能觀察到效果。可以視覺化分散式系統中每個服務之間的回應時間的追蹤解決方案不僅可以更快地顯示結果，而且可以協助識別成為瓶頸的系統。您可以透過從日誌檔案中取得訊息關聯 ID 來識別瓶頸系統。每個請求在經過負載測試的所有系統中保留相同的 ID。

使用關聯 ID 可協助您追蹤單一訊息通過平台中所有不同元件的整個旅程。使用此訊息，您可以計算訊息正在周遊的每個單一元件的處理時間 (processing_time = departure_time – arrival_time) 並識別最慢的元件。Zipkin、Jaeger 和 AWS X-Ray 是此領域的傑出解決方案。

為了取得最可靠的結果，請選擇支援設定恆定請求速率的工具。這意味著如果目標系統變慢，測試工具的並行必須增加以保持請求/秒恆定。在系統開始回應較慢時，它將佔用更多執行緒並降低負載產生工具的請求速率。具有恆定請求速率的工具必須在發生時增加並行，您會更快地看到失敗。您將透過延遲甚至失敗的請求來測量，而不是透過實現的請求/秒來測量降級。

我的應用程式是否運作？

通常，您不會建立高負載，而是建立合理數量的請求來驗證功能。您還可以在客戶不造訪測試流程時定期針對生產執行此操作，以進行另一層監控。

作為捷徑，已為負載測試建立的案例可以在設定較低負載的生產中重複使用。