Agent Runtime bietet Bereitstellungsparameter, mit denen Sie die Leistung Ihrer Agents optimieren und skalieren können. Durch die Konfiguration dieser Parameter können Sie unvorhersehbare oder sprunghafte Trafficmuster effektiv bewältigen.
Auf dieser Seite werden Best Practices zur Optimierung und Skalierung der Leistung für die Agent-Laufzeit beschrieben. Dabei werden die folgenden Szenarien behandelt:
Die Szenarien zeigen, wie Sie Bereitstellungsparameter verwenden, um häufige Leistungsengpässe zu beheben, insbesondere bei unvorhersehbaren, sprunghaften Traffic-Mustern in realen Anwendungen.
Kaltstartproblem
Ein Kaltstart erfolgt, wenn eine Anfrage eingeht und keine inaktiven Instanzen oder Container zur Verarbeitung verfügbar sind. In diesem Fall muss die Agent-Laufzeit eine neue Instanz oder einen neuen Container starten. Dadurch wird die Latenz der Anfrage erheblich erhöht.
Wenn Sie beispielsweise 300 gleichzeitige Anfragen an einen Agenten mit dem Standardwert min_instances=1 senden, können die folgenden Ergebnisse angezeigt werden:
Kaltstart (erster Lauf): durchschnittliche Latenz von etwa 4,7 Sekunden.
Warmstart (sofortige zweite Ausführung): durchschnittliche Latenz von etwa 0,4 Sekunden.
Der Overhead von mehr als vier Sekunden ist fast ausschließlich auf das Starten neuer Instanzen zur Verarbeitung der Last zurückzuführen.
Mit den folgenden Methoden können Sie das Kaltstartproblem beheben:
Legen Sie einen
min_instances-Wert fest, der hoch genug ist, um Ihren Referenz-Traffic zu bewältigen. Wenn Siemin_instances=10beispielsweise auf den Beispiel-Agent festlegen, kann die durchschnittliche Latenz für einen Kaltstart auf etwa 1,4 Sekunden reduziert werden. Legen Sie für Anwendungen mit unregelmäßigem oder hohem Trafficmin_instancesauf einen Wert fest, der Ihre typische Last bewältigen kann, ohne dass eine Skalierung von 1 erforderlich ist. Der Höchstwert ist 10.Senden Sie eine stabile, kontinuierliche und vorhersagbare Last an die Agent Runtime über eine Warteschlange. Wenn Sie beispielsweise einen Lasttest mit 1.500 Anfragen pro Minute (25 Anfragen pro Sekunde) für 60 Sekunden für einen auf dem Agent Development Kit (ADK) basierenden Agenten mit
min_instances=10und dem Standardwertconcurrency(9) ausführen, kann das folgende Ergebnis erzielt werden:- Die durchschnittliche Latenz ist mit etwa 1,6 Sekunden konstant niedrig.
Eine stabile, kontinuierliche Last hält den Dienst warm und führt zu einer optimalen Leistung.
Unterausgelastete asynchrone Worker
Standardmäßig ist container_concurrency für synchronen Code konfiguriert, bei dem jede Agent Platform-Instanz jeweils nur eine Anfrage verarbeitet.
Asynchrone Agenten, z. B. solche, die auf dem Agent Development Kit (ADK) basieren, können mehrere E/A-gebundene Anfragen (z. B. LLM- oder Tool-Aufrufe) gleichzeitig verarbeiten.
Wenn Sie beispielsweise 300 gleichzeitige Anfragen an einen ADK-basierten Agenten mit min_instances=10 und dem Standardwert container_concurrency=9 senden, kann das folgende Ergebnis erzielt werden:
- Die mediane Latenz beträgt etwa 4 Sekunden, die maximale Latenz steigt jedoch auf 60 Sekunden. Dies deutet darauf hin, dass Anfragen stark in die Warteschlange gestellt werden, während der Dienst langsam skaliert wird.
Um die Unterauslastung asynchroner Worker zu verringern, erhöhen Sie container_concurrency, damit jede Agent Platform-Instanz mehrere Anfragen verarbeiten kann. Die Anzahl der gleichzeitigen Anfragen, die von jedem Agent-Prozess verarbeitet werden können, ist container_concurrency / 9. Der Wert 9 steht für die Anzahl der Agent-Prozesse, die parallel in jedem Container ausgeführt werden.
Wenn Sie beispielsweise 300 gleichzeitige Anfragen mit min_instances=10 und container_concurrency=36 an denselben ADK-basierten Agenten senden, kann das folgende Ergebnis erzielt werden:
- Die maximale Latenz sinkt von 60 Sekunden auf etwa 7 Sekunden. Das zeigt, dass vorhandene Instanzen den Traffic-Anstieg besser auffangen können.
Bei asynchronen Agents (z. B. ADK-basierten Agents) sollten Sie container_concurrency als Ausgangspunkt auf ein Vielfaches von 9 (z. B. 36) festlegen. Dadurch wird die Reaktionsfähigkeit auf Traffic-Spitzen verbessert und die Latenz beim Skalieren reduziert.
Wenn Sie den Wert für container_concurrency zu hoch festlegen, kann es zu Fehlern aufgrund fehlenden Arbeitsspeichers (OOM, Out-of-memory) kommen.
Nächste Schritte
Bereitgestellte Agents verwalten
Hier erfahren Sie, wie Sie Agents verwalten, die in der verwalteten Laufzeit der Agent Platform bereitgestellt wurden.