Auf dieser Seite finden Sie Best Practices für Lasttests Ihres Cloud Run-Dienstes. Sie können damit feststellen, ob der Dienst während der Produktion erfolgreich skaliert wird und Engpässe finden, die die Skalierung verhindern.
Tests, die vor dem Lasttest ausgeführt werden
Identifizieren und beheben Sie Nebenläufigkeitsprobleme in einer Entwicklungs- oder kleinen Testumgebung, bevor Sie mit den Lasttests fortfahren. Messen Sie die Container-Nebenläufigkeit, bevor Sie einen Lasttest durchführen, und achten Sie darauf, dass Ihr Cloud Run-Dienst zuverlässig gestartet wird.
Konzentrieren Sie sich bei Ihren Containertests auf kleine inkrementelle Werte bei manuell skalierten Ausführungen. Sie können die manuelle Skalierung in Cloud Run angleichen. Dazu setzen Sie maximale Instanzen auf den Wert, auf den Sie skalieren möchten.
Wenn Sie Ihr Container-Image erst kürzlich erstellt oder geändert haben, sollten Sie dies unabhängig voneinander testen, bevor Sie einen Lasttest durchführen.
Sie sollten auch andere Arten von Leistungsproblemen prüfen, z. B. übermäßige Latenz und CPU-Auslastung, bevor Sie einen groß angelegten Lasttest durchführen.
max instances korrekt verwenden
In Cloud Run wird eine maximale Anzahl von Instanzen erzwungen, um die Skalierung eines Dienstes zu begrenzen. Die Standardmaximalanzahl von Instanzen beträgt 100. Wenn Sie davon ausgehen, dass Ihr Belastungstest diesen Standardwert überschreitet, wenden Sie sich an Ihr Account-Management-Team bei Google und legen Sie ein neues Maximum fest. Wenn Sie noch keine Geschäftsbeziehung zu einem Account-Management-Team haben, wenden Sie sich an den Google Cloud-Vertrieb.
Die maximale Anzahl der Instanzen, die Sie auswählen können, hängt von Ihren CPU- und Speicherlimits sowie von der Region ab, in der Sie die Bereitstellung vornehmen.
Diese Limits werden durch ein Kontingentlimit verwaltet und können durch einen Anfrage zur Erhöhung des Kontingentlimits erhöht werden.
Lasttest in der Region us-central1
Die Google Cloud-Region us-central1 bietet ein hohes Kontingentlimit. Daher empfiehlt Google, Lasttests in us-central1 durchzuführen. Stimmen Sie sich mit Ihrem Account-Team ab und reichen Sie einen Support-Fall mit Angaben zu Zeit und Umfang des Tests ein, wenn Sie sich den Kontingentlimits nähern wollen.
Geeignete CPU-Auslastung und Dienstinitialisierungsprofil testen
Im Idealfall stellen Sie eine Testversion Ihres Dienstes in Cloud Run bereit und führen direkt einen Lasttest durch. In einigen Fällen können Sie jedoch möglicherweise keine Testversion Ihres Dienstes bereitstellen. Ihr Cloud Run-Dienst ist beispielsweise möglicherweise Teil eines komplexen Systems, das sich nur schwer in einer Testumgebung replizieren lässt.
In diesen Fällen können Sie die Leistung Ihres Dienstes annähernd ermitteln, indem Sie ihn mit einem einfacheren Dienst mit vergleichbarer CPU-Auslastung und vergleichbaren Initialisierungszeiten simulieren.
Die Initialisierungszeit ist besonders für eine schnelle Skalierung wichtig. Denken Sie daran, dass es auch problematisch ist, mit etwas zu Einfachem zu testen. Vermeiden Sie es beispielsweise, mit einem einfachen hello world-Dienst zu testen, der empfangene Anfragen ohne Verarbeitung zurückgibt.
Mit einem Test-Harnisch Lasten generieren
Sie können Testlasten generieren, die einen kontrollierten Traffic-Anstieg verursachen, indem Sie einen Test-Harnisch nutzen (z. B. JMeter). Sie können die Anzahl der JMeter-Threadgruppen und die Verzögerung zwischen den Anfragen im JMeter-Test verwenden, um die Last zu erhöhen.
Sie können auch einfache HTTP-Anfragen senden oder eine Browser-Sitzung mit JMeter aufzeichnen. Mit Cloud Run können Sie Ihren Dienst mithilfe der Entwicklerauthentifizierung ohne Internetzugriff testen. Dies ermöglicht den Zugriff von einem Test-Harnisch wie JMeter, der auf einer virtuellen Compute Engine-Maschine ausgeführt wird, die mit einer mit dem Projekt verbundenen Virtual Private Cloud verbunden ist.
Generieren Sie keine Last mit Tools, bei denen die Rate und die Nebenläufigkeit nicht gesteuert werden können. Pub/Sub ist eine schlechte Wahl für die Generierung von Last, da Sie die Rate des Traffics und die Anzahl der Clients nicht steuern können. Wenn Sie die Rate und die Nebenläufigkeit nicht kennen, wissen Sie nicht, was Sie testen.
Detaillierte Loganalyse mit exportierten Logs verwenden
Sie benötigen eine sekundengenaue Analyse der Ereignisse, um zu verstehen, wie Ihr Cloud Run-Dienst auf schnelle Traffic-Spitzen reagiert. Dazu ist eine Logging-Analyse erforderlich, da die Granularität der Monitoring-Daten nicht fein genug ist. Mithilfe der Loganalyse können Sie auch die Gründe für Anfragen mit hoher Latenz untersuchen.
Wenn Sie Protokolle schreiben, können Sie eine bessere Protokollierungsleistung erzielen, indem Sie direkt in stdout schreiben, anstatt eine Cloud Logging-Clientbibliothek zu verwenden.
Wenn Sie einen Logexport vor Beginn des Tests einrichten möchten, erstellen Sie eine Logsenke mit dem Ziel BigQuery und einem „Einschließen“-Filter, z. B.:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Falsche Kaltstarts vermeiden
Legen Sie die Mindestanzahl von Instanzen auf mindestens 1 fest, um Kaltstarts für Nutzer zu minimieren.
Lineare Hochskalierung Ihres Dienstes sicherstellen
Wiederholen Sie den Test bei verschiedenen Lasten, damit Sie sicher sein können, dass Ihr Cloud Run-Dienst linear mit der Last skaliert und nicht bei einer Last, die geringer ist als die, die Sie in der Produktion erwarten, einen begrenzenden Engpass erreicht.
Ergebnisse in Colab analysieren und visualisieren
Mit den Zusammenfassungsdiagrammen erhalten Sie einen Überblick über die Ergebnisse, um die detaillierte Loganalyse mithilfe von exportierten Logs zu ergänzen.
Mit den Monitoring-Diagrammen können Sie Folgendes herausfinden:
- Wie schnell werden neue Instanzen auf die Sekunde genau erstellt und initialisiert?
- Wie gleichmäßig werden Anfragen auf verschiedene Instanzen verteilt?
- Wie schnell kann die Latenz bei verschiedenen Perzentilwerten auf einen stabilen Wert gesenkt werden?
Sie können die Benutzeroberfläche der Google Cloud Console für BigQuery verwenden, um das exportierte Logschema zu untersuchen und eine Vorschau der Ergebnisse aufzurufen. Führen Sie die Abfragen aus und stellen Sie die Ergebnisse mit Colab dar. Diese Plattform ist bereits in BigQuery, Pandas und Matplotlab eingebunden. Colab lässt sich auch problemlos in leistungsstarke Tools zur Datenvisualisierung wie Seaborn einbinden.
Engpässe finden
Mit Lasttests können Sie sowohl ineffizienten Code als auch Skalierungsengpässe erkennen. Ineffizienter Code führt zu höheren Kosten, da mehr Traffic verarbeitet werden muss, verhindert aber nicht unbedingt die Skalierung. So kann beispielsweise eine Abhängigkeit von einer Datenbankübersetzung mit Sperrung auf Tabellenebene einen Engpass darstellen, der eine Skalierung des Cloud Run-Dienstes verhindert, da nur eine Transaktion gleichzeitig ausgeführt werden kann.
Leistung prüfen, wie sie der Kunde erlebt
Sie können Logs abfragen, die mit JMeter erfasst wurden. Diese Logs enthalten Latenzen, die am Client gemessen wurden. Da Servertesttools wie JMeter nicht mit einem Browser oder mobilen Client identisch sind, können Sie auch einen Test mit einem browserbasierten Framework ausführen, wie z. B. Selenium Webdriver oder ein mobiles Testframework für Clients. Achten Sie auf zu hohe maximale Latenzen aufgrund der TLS-Verbindungsinitialisierung, die die Ergebnisse durch Ausreißer verfälschen können.
Zusammenfassung der Best Practices
Führen Sie einen Lasttest durch, um festzustellen, ob die Migration zu Cloud Run die richtige Entscheidung ist und ob Ihr Dienst auf den maximal erwarteten Traffic skaliert werden kann. Führen Sie den Test mit einem Harnisch wie JMeter aus. Logs zur detaillierten Analyse nach BigQuery exportieren.