以下測試結果最初發佈在《NGINX Ingress Controller 在動態 Kubernetes 雲端環境中的效能測試》部落格文章中。請閱讀部落格文章獲取完整的詳細資訊，包括測試方法和規格。
執行緩慢的應用程式會迅速導致客戶流失
選擇流量管理工具（尤其是對於敏捷 Kubernetes 應用程式而言）時，該工具可能增加的延遲量是最重要的因素之一。畢竟，執行速度緩慢的應用程式會迅速導致客戶流失。我們比較了三個以 NGINX 為基礎的 Ingress Controller 在真實的多雲端環境中的效能，並測量了用戶端連線在網際網路中的延遲情況：
• 以 NGINX 開放原始碼版為基礎的 NGINX Ingress Controller，由 Kubernetes 社群維護。我們在這裡將其稱為「社群版」。我們從 Google Container Registry 中擷取了其 0.34.1版本的鏡像，用於此次測試。
• 以 NGINX 開放原始碼版為基礎的 NGINX Ingress Controller 1.8.0，由 NGINX 維護。我們在這裡將其稱為「NGINX 開放原始碼版」。
• 以 F5 NGINX Plus 為基礎的 NGINX Ingress Controller 1.8.0，由 NGINX 維護。我們在這裡將其稱為「NGINX Plus 版」。
我們產生了穩定的用戶端流量，並使用這些流量對 Ingress Controller 進行壓力測試，收集了以下效能指標：
• 延遲率 —— 用戶端從產生請求到接收回應所用的時間。我們在報告中用百分位分佈的形式來表示延遲率。例如，如果有 100 個延遲測試樣本，則第 99% 個的值是 100 次測試中僅次於最慢值的回應延遲。
• 連線逾時 —— 由於 Ingress Controller 在特定時間內無法回應請求而被靜默中斷或丟棄的TCP 連線。
• 讀取錯誤 —— 嘗試讀取連線失敗，因為來自 Ingress Controller 的通訊端已關閉。
• 連線錯誤 —— 用戶端和 Ingress Controller 之間未建立的 TCP 連線。
我們在兩種情況下進行了測試。在「靜態部署」中，後端 Pod 副本的數量在整個測試執行期間保持不變，一直是五個。在「動態部署」中，我們使用一個指令碼定期將副本數量擴展到七個，然後再恢復到五個。正如以下結果所示，我們發現只有 NGINX Plus 版本在 Pod 副本數量上升和下降時不會產生高延遲。
靜態部署的延遲結果
如圖所示，在靜態部署後端應用程式時，三個 NGINX Ingress Controller 具有相似的效能。考量到它們都以 NGINX 開放原始碼版為基礎建構，並且靜態部署不需要從 Ingress Controller重新配置，這一結果也很合理。
動態部署的延遲結果
該圖顯示了在定期將後端應用程式從五個 Pod 副本擴展到七個又減少到五個的動態部署下，每種 NGINX Ingress Controller 產生的延遲。
很明顯，只有 NGINX Plus 版在這種環境中表現良好，一直到 99.99% 百分位都幾乎沒有任何延遲。社群版和 NGINX 開放原始碼版雖然具有截然不同的延遲模式，但都在很低的百分位上產生了明顯的延遲。
• 社群版：延遲呈緩慢但穩定的上升狀態，在第 99 個百分位達到大約 5000 毫秒（5 秒）並在之後趨於穩定。
• NGINX 開放原始碼版：延遲率呈急劇攀升狀態，在第 99 個百分位達到大約 32 秒，到第99.99 個百分位又變成了 60 秒。
社群版和 NGINX 開放原始碼版所經歷的延遲是由 NGINX 配置更新和重新載入（以回應後端應用程式不斷變化的端點）後出現的錯誤和逾時引起的，具體內容我們將在下文「動態部署中的逾時和錯誤結果」部分進一步討論。
動態部署中的逾時和錯誤結果
此表更詳細地顯示了引起延遲的原因：
使用 NGINX 開放原始碼版 Ingress Controller 時，每次更改後端應用程式端點後都需要更新並重新載入 NGINX 配置，這會導致許多連線錯誤、連線逾時和讀取錯誤的問題。當用戶端嘗試連線不再分配給 NGINX 處理程序的通訊端時，系統會在 NGINX 重新載入的短時間內發生連線/通訊端錯誤。當用戶端與 Ingress Controller 建立連線但後端端點不再可用時，會發生連線逾時。錯誤和逾時會嚴重影響延遲率，導致延遲率在第 99 個百分位激增到 32 秒，然後在第 99.99 個百分位變成 60 秒。
使用社群版 Ingress Controller 時，端點隨著後端應用程式的調整而更改，引發了 8809 連線逾時。社群版 Ingress Controller 使用 Lua 程式碼來避免在端點變更時重新載入配置。結果顯示，在 NGINX 內部執行，用來偵測端點變更的 Lua 處理常式解決了 NGINX 開放原始碼版 IngressController 的一些效能限制問題 —— 這些限制是由每次更改端點後都重新載入配置引起的。儘管如此，連線逾時仍然會發生，導致更高百分位的顯著延遲。此外，正如我們在第 6 章中所討論的，在以 OpenResty 為基礎的 Ingress Controller（包括社群版本）中使用 Lua 可能會帶來意想不到的風險。
而使用 NGINX Plus 版時沒有錯誤或逾時 —— 動態環境對效能幾乎沒有影響。這是因為 NGINXPlus 使用了 NGINX Plus API 在端點變更後動態更新 NGINX 配置。如上文所述，它的最高延遲時間為 254 毫秒，發生在第 99.9999 個百分位。
結語
效能結果表明，要想完全消除動態 Kubernetes 雲端環境中的逾時和錯誤，Ingress Controller就必須動態適應後端端點的變更，且無需使用事件處理常式或重新載入配置。根據這些結果，NGINX Plus API 可以說是在動態環境中重新配置 NGINX 的最佳解決方案。在我們的測試中，只有以 NGINX Plus 為基礎的 NGINX Ingress Controller 在高度動態的 Kubernetes 環境中實現了符合使用者需求的完美效能。