Agent Runtime bietet Bereitstellungsparameter, mit denen Sie die Leistung Ihrer Agenten optimieren und skalieren können. Durch die Konfiguration dieser Parameter können Sie unvorhersehbare oder sprunghafte Trafficmuster effektiv verarbeiten.
Auf dieser Seite werden Best Practices zur Optimierung und Skalierung der Leistung für Agent Runtime beschrieben. Dabei werden die folgenden Szenarien behandelt:
In den Szenarien wird gezeigt, wie Sie Bereitstellungsparameter verwenden können, um häufige Leistungs engpässe zu beheben, insbesondere bei unvorhersehbaren, sprunghaften Trafficmustern in realen Anwendungen.
Kaltstartproblem
Ein Kaltstart tritt auf, wenn eine Anfrage eingeht und keine inaktiven Instanzen oder Container verfügbar sind, um sie zu verarbeiten. In diesem Fall muss Agent Runtime eine neue Instanz oder einen neuen Container starten. Dadurch erhöht sich die Latenz der Anfrage erheblich.
Wenn Sie beispielsweise 300 gleichzeitige Anfragen an einen Agenten mit dem Standardwert min_instances=1 senden, können die folgenden Ergebnisse auftreten:
Kaltstart (erste Ausführung): durchschnittliche Latenz von etwa 4,7 Sekunden.
Warmstart (sofortige zweite Ausführung): durchschnittliche Latenz von etwa 0,4 Sekunden.
Der Mehraufwand von mehr als vier Sekunden ist fast ausschließlich auf das Starten neuer Instanzen zurückzuführen, um die Last zu verarbeiten.
Mit den folgenden Methoden können Sie das Kaltstartproblem beheben:
Legen Sie einen Wert für
min_instancesfest, der hoch genug ist, um Ihren Baseline-Traffic zu verarbeiten. Wenn Sie beispielsweisemin_instances=10für den Beispielagenten festlegen, kann die durchschnittliche Latenz für einen Kaltstart auf etwa 1,4 Sekunden reduziert werden. Legen Sie für Anwendungen mit sprunghaftem oder hohem Trafficmin_instancesauf einen Wert fest, der die typische Last verarbeiten kann, ohne dass eine Skalierung von 1 erforderlich ist. Der Maximalwert ist 10.Senden Sie mit einer Warteschlange eine stabile, kontinuierliche und vorhersagbare Last an Agent Runtime. Wenn Sie beispielsweise einen Lasttest mit 1.500 Abfragen pro Minute (25 Abfragen pro Sekunde) für 60 Sekunden auf einem Agent Development Kit (ADK)-basierten 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, wobei jede Agent Platform-Instanz jeweils nur eine Anfrage verarbeitet.
Asynchrone Agenten wie solche, die auf dem
Agent Development Kit (ADK) basieren, können mehrere
E/A-gebundene Anfragen (z. B. LLM- oder Toolaufrufe) 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 mittlere Latenz beträgt etwa 4 Sekunden, die maximale Latenz steigt jedoch auf 60 Sekunden. Das bedeutet, dass Anfragen stark in die Warteschlange gestellt werden, während der Dienst langsam skaliert wird.
Um unterausgelastete asynchrone Worker zu vermeiden, erhöhen Sie container_concurrency, damit jede Agent Platform-Instanz mehrere Anfragen verarbeiten kann. Die Anzahl der gleichzeitigen Anfragen, die jeder Agentenprozess verarbeiten kann, ist container_concurrency / 9. Der Wert 9 steht für die Anzahl der Agentenprozesse, die parallel in jedem Container ausgeführt werden.
Wenn Sie beispielsweise 300 gleichzeitige Anfragen an denselben ADK-basierten Agenten mit min_instances=10 und container_concurrency=36 senden, kann das folgende Ergebnis erzielt werden:
- Die maximale Latenz sinkt von 60 Sekunden auf etwa 7 Sekunden. Das zeigt, dass vorhandene Instanzen den Anstieg des Traffics effektiver aufnehmen können.
Legen Sie für asynchrone Agenten (z. B. ADK-basierte Agenten) container_concurrency als Ausgangspunkt auf ein Vielfaches von 9 fest (z. B. 36). Dadurch wird die Reaktionsfähigkeit auf Trafficspitzen verbessert und die Latenz beim Skalieren reduziert.
Wenn Sie den Wert für container_concurrency zu hoch festlegen, kann es zu Fehlern aufgrund von unzureichendem Arbeitsspeicher (Out-of-Memory, OOM) kommen.
Nächste Schritte
Bereitgestellte Agenten verwalten
Informationen zum Verwalten von Agenten, die in der verwalteten Laufzeit von Agent Platform bereitgestellt wurden.