Agent Runtime 提供部署參數，可讓您最佳化及擴充代理的效能。設定這些參數，即可有效處理無法預測或流量激增的情況。
本頁說明最佳化及擴充 Agent Runtime 效能的最佳做法，涵蓋下列情境：
這些情境說明如何使用部署參數解決常見的效能瓶頸，特別是實際應用程式中無法預測、流量激增的模式。
冷啟動問題
當要求送達時，如果沒有閒置的執行個體或容器可處理，Agent Runtime 就必須啟動新的執行個體或容器，這稱為冷啟動。這會大幅增加要求的延遲時間。
舉例來說，如果將 300 個並行要求傳送至預設 min_instances=1 的代理，可能會顯示下列結果：
冷啟動 (首次執行)：平均延遲時間約為 4.7 秒。
暖啟動 (立即第二次執行)：平均延遲時間約為 0.4 秒。
超過四秒的負擔幾乎完全是因為啟動新執行個體來處理負載。
請嘗試下列方法，緩解冷啟動問題：
請將
min_instances值設得夠高，足以處理基準流量。舉例來說，將min_instances=10設為範例代理，可將冷啟動的平均延遲時間縮短至約 1.4 秒。如果應用程式的流量不穩定或偏高，請將min_instances設為可處理一般負載的值，不必從 1 開始調度資源。如需可接受的值範圍，請參閱ReasoningEngineSpecREST 資源參考資料。使用佇列，向 Agent Runtime 傳送穩定、連續且可預測的負載。舉例來說，在採用
min_instances=10和預設concurrency(9) 的 Agent Development Kit (ADK) 代理上，以每分鐘 1,500 次查詢 (每秒 25 次查詢) 的速度，持續執行 60 秒的負載測試，可能會產生下列結果：- 平均延遲時間持續偏低，約為 1.6 秒。
穩定、持續的負載可讓服務保持暖機狀態，並達到最佳效能。
非同步 worker 使用率偏低
根據預設，container_concurrency 會設定為同步程式碼，每個 Agent Platform 執行個體一次只會處理一項要求。非同步代理 (例如以 Agent Development Kit (ADK) 為基礎的代理) 可同時處理多個 I/O 繫結要求 (例如 LLM 或工具呼叫)。
舉例來說，如果同時向 ADK 代理傳送 300 個並行要求，並使用 min_instances=10 和預設的 container_concurrency=9，可能會產生下列結果：
- 雖然延遲時間中位數約為 4 秒，但最大延遲時間會飆升至 60 秒。這表示服務在緩慢水平擴展時，要求會大量排入佇列。
如要減少未充分利用的非同步 worker，請提高 container_concurrency，讓每個代理平台執行個體處理多個要求。每個代理程式程序可處理的並行要求數量為 container_concurrency / 9。值 9 代表每個容器中平行執行的代理程式程序數量。
舉例來說，如果同時向同一個以 ADK 為基礎的代理傳送 300 個並行要求，並使用 min_instances=10 和 container_concurrency=36，可能會產生下列結果：
- 最大延遲時間從 60 秒縮短至約 7 秒。這表示現有執行個體能更有效地吸收流量高峰。
如果是非同步代理 (例如以 ADK 為基礎的代理)，請先將 container_concurrency 設為 9 的倍數 (例如 36)。這可提升對流量高峰的反應速度，並減少水平擴展造成的延遲。
請注意，如果將 container_concurrency 值設得太高，可能會發生記憶體不足 (OOM) 錯誤。