Envoy 效能基準測試的最佳實務為何？
沒有單一的 QPS、延遲或輸送量負擔可以描述像 Envoy 這樣的網路代理。相反地，任何測量都需要考慮情境，透過適當的設定和負載測試 Envoy，確保與其他系統進行公平的比較。因此，我們無法提供規範的基準設定，而是提供以下指導：
應該使用發行的 Envoy 二進位檔。如果自行建置，請確保在 Bazel 命令列上使用
-c opt。當使用 Envoy 的 point release 時，請確保使用最新的 point release；鑑於 Envoy 開發的步調，在發表關於 Envoy 效能的聲明時，選擇舊版本是不合理的。同樣地，如果使用主分支的建置版本，請盡職調查，確保沒有回歸或效能提升發生在您的基準測試工作附近，並且您接近 HEAD。應取消設定 Envoy CLI 旗標
--concurrency（在您的機器上為每個邏輯核心提供一個工作執行緒），或將其設定為與您比較中的其他網路代理可用的核心/執行緒數量相符。停用斷路器。基準測試期間常見的問題是 Envoy 的預設斷路器限制較低，導致連線和請求排隊。
停用 dynamic_stats。如果您正在測量與直接連線相比的負擔，您可能需要考慮透過 reject_all 停用所有統計資料。
確保網路和 HTTP 過濾器鏈反映與 Envoy 比較的系統中的可比功能。
確保 TLS 設定（如果有）是實際的，並且在任何比較中使用一致的密碼。工作階段重用可能會對結果產生重大影響，應透過 listener SSL 統計資料 追蹤。
確保 HTTP/2 設定，特別是那些影響流量控制和串流並發性的設定，在任何比較中都是一致的。理想情況下，在優化任何 HTTP/2 設定時，應考慮 BDP 和網路連結延遲。
在監聽器和叢集統計資料中驗證串流、連線和錯誤的數量是否與任何給定實驗中的預期相符。
請確保您知道負載產生器建立的連線是如何分配到 Envoy 工作執行緒上的。對於使用低連線數和完美保持連線的基準測試而言，這一點尤其重要。您應該知道，Envoy 會將給定連線的所有串流分配給單一工作執行緒。這表示，例如，如果您有 72 個邏輯核心和工作執行緒，但您的負載產生器只有一個 HTTP/2 連線，則只有 1 個工作執行緒會處於活動狀態。
請確保請求釋放時序的期望與預期一致。某些負載產生器會產生自然抖動和/或批次時序。這最終可能會在某些測試中成為意想不到的主要因素。
您的負載產生器如何重複使用連線的具體細節是一個重要的因素（例如 MRU、隨機、LRU 等），因為這會影響工作分配。
如果您嘗試測量小（例如 < 1 毫秒）延遲，請確保測量工具和環境具有所需的靈敏度，並且雜訊底限足夠低。
對您的 bootstrap 或 xDS 組態持批判態度。理想情況下，每一行都有動機，並且對於正在考慮的基準測試是必要的。
考慮使用 Nighthawk 作為您的負載產生器和測量工具。我們致力於在此工具中建立基準測試和延遲測量的最佳實務。
在基準測試執行期間檢查 Envoy 的
perf設定檔，例如使用 火焰圖。驗證 Envoy 是否將時間花費在測試下預期的必要工作上，而不是一些不相關或無關的工作上。熟悉延遲測量的最佳實務。特別是，永遠不要在最大負載下測量延遲，這通常沒有意義或反映真實的系統效能；目標是在 QPS-延遲曲線的膝部以下進行測量。偏好使用開放式而非封閉式迴路負載產生器。
避免基準測試犯罪。