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 durchgeführt werden müssen
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 Containertests auf kleine inkrementelle Mengen bei manuell skalierten Läufen. 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 wie übermäßige Latenz und CPU-Auslastung prüfen, bevor Sie einen umfangreichen 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 maximale Standardanzahl von Instanzen beträgt 100. Wenn Sie davon ausgehen, dass Ihr Belastungstest diesen Standardwert überschreiten wird, wenden Sie sich an Ihr Account-Management-Team bei Google, um einen neuen Höchstwert festzulegen. Wenn Sie noch keine Geschäftsbeziehung zu einem Account-Management-Team haben, wenden Sie sich an den Vertrieb. Google Cloud
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 europe-west1
Die Google Cloud Region europe-west1 bietet ein hohes Kontingentlimit. Google empfiehlt daher, Lasttests in europe-west1 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.
Geeignetes CPU-Auslastungs- 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 ist es jedoch möglicherweise nicht möglich, eine Testversion Ihres Dienstes bereitzustellen. Ihr Cloud Run-Dienst ist beispielsweise möglicherweise Teil eines komplexen Ökosystems, das in einer Testumgebung schwer zu replizieren ist.
In diesen Fällen können Sie die Leistung Ihres Dienstes näherungsweise bestimmen, indem Sie ihn mit einem einfacheren Dienst simulieren, der eine vergleichbare CPU-Auslastung und vergleichbare Initialisierungszeiten hat.
Die Initialisierungszeit ist besonders wichtig für eine schnelle Skalierung. 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 Last erhöhen, indem Sie die Anzahl der JMeter-Threadgruppen und die Verzögerung zwischen Anfragen im JMeter-Test erhöhen.
Sie können auch einfache HTTP-Anfragen senden oder eine Browsersitzung mit JMeter aufzeichnen. Mit Cloud Run können Sie Ihren Dienst ohne Internetzugang testen, indem Sie die Entwicklerauthentifizierung verwenden. 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 (VPC) 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. Mit der Loganalyse können Sie auch die Gründe für Anfragen mit hoher Latenz untersuchen.
Wenn Sie Logs schreiben, können Sie eine bessere Logging-Leistung 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
Um Kaltstarts für Nutzer zu minimieren, legen Sie die Mindestanzahl von Instanzen auf mindestens 1 fest.
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 Colaboratory analysieren und visualisieren
Mit den zusammenfassenden Monitoring-Diagrammen erhalten Sie einen allgemeinen Überblick über die Ergebnisse, um die detaillierte Loganalyse mit exportierten Logs zu ergänzen.
Mithilfe der Monitoring-Diagramme können Sie Folgendes herausfinden:
- Wie schnell werden neue Instanzen auf die Sekunde genau erstellt und initialisiert?
- Wie gleichmäßig werden Anfragen auf die verschiedenen Instanzen verteilt?
- Wie schnell kann die Latenz bei verschiedenen Perzentilen auf einen Steady-State-Wert gesenkt werden?
Sie können die Google Cloud -Konsolenbenutzeroberfläche 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. Colab ist bereits in BigQuery, Pandas und Matplotlib integriert. Colab lässt sich auch problemlos in umfangreiche Datenvisualisierungstools wie Seaborn einbinden.
Engpässe finden
Mit Lasttests können Sie sowohl ineffizienten Code als auch Skalierungsengpässe ermitteln. Ineffizienter Code führt zu höheren Kosten, da er mehr Traffic verarbeiten 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 von JMeter erfasst wurden. Diese Logs enthalten Latenzen, die auf dem 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 übermäßige maximale Latenzen aufgrund der Initialisierung der TLS-Verbindung, die Ergebnisse mit Ausreißern verzerren können.
Zusammenfassung der Best Practices
Führen Sie einen Lasttest durch, um festzustellen, ob die Migration zu Cloud Run die richtige Wahl 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.