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 sollen
Gleichzeitigkeitsprobleme in einer Entwicklungs- oder kleinen Testumgebung ermitteln und beheben, bevor Sie Lasttests ausführen. Messen Sie die Gleichzeitigkeit von Containern, bevor Sie einen Lasttest durchführen. Prüfen Sie, ob Ihr Cloud Run-Dienst zuverlässig gestartet wird.
Konzentrieren Sie sich auf Containertests mit kleinen inkrementellen Zählungen in 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. eine übermäßige Latenz und CPU-Auslastung, bevor Sie einen umfangreichen Lasttest ausführen.
max instances korrekt verwenden
Cloud Run erzwingt maximale Instanzen, um die Skalierung eines Dienstes zu begrenzen. Die standardmäßige maximale Anzahl von Instanzen ist 100. Wenn Sie davon ausgehen, dass Ihr Lasttest diesen Standardwert überschreitet, wenden Sie sich an Ihr Account-Management-Team von Google und legen Sie einen neuen Höchstwert fest. Wenn Sie noch keine Geschäftsbeziehung zu einem Account-Management-Team haben, wenden Sie sich an den Google Cloud-Vertrieb.
Die maximale Anzahl von Instanzen, die Sie auswählen können, hängt von Ihren CPU-Limits und Speicherlimits sowie der Region ab, in der Sie die Bereitstellung durchführen.
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. 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 das Dienstinitialisierungsprofil testen
Im Idealfall stellen Sie eine Testversion Ihres Dienstes in Cloud Run und einen Lasttest direkt bereit. In einigen Fällen kann es jedoch nicht möglich sein, eine Testversion Ihres Dienstes bereitzustellen. Beispielsweise kann Ihr Cloud Run-Dienst Teil einer komplexen Umgebung sein, die sich in einer Testumgebung nur schwer replizieren lässt.
In diesen Fällen können Sie die Leistung Ihres Dienstes schätzen, indem Sie ihn mit einem einfacheren Dienst simulieren, der eine vergleichbare CPU-Auslastung und vergleichbare Initialisierungszeiten hat.
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 beispielsweise Tests mit einem einfachen hello world-Dienst, 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-Thread-Gruppen verwenden und die Verzögerung zwischen den Anfragen im JMeter-Test erhöhen, um die Last zu erhöhen.
Sie können auch einfache HTTP-Anfragen senden oder eine Browsersitzung 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 von Tools, bei denen die Rate und die Gleichzeitigkeit 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 Gleichzeitigkeit 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, wenn Sie direkt in stdout schreiben, anstatt eine Cloud Logging-Clientbibliothek zu verwenden.
Wenn Sie vor dem Start des Tests einen Logexport einrichten möchten, erstellen Sie eine Logsenke mit dem BigQuery-Ziel und einem Einschlussfilter. Beispiel:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Unerwünschte Kaltstarts vermeiden
Wenn Sie die Kaltstarts für Nutzer minimieren möchten, legen Sie die Mindestanzahl an Instanzen auf mindestens 1 fest.
Lineares Skalieren von Diensten gewährleisten
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
Verwenden Sie die zusammenfassenden Monitoring-Diagramme, um ein allgemeines Verständnis der Ergebnisse zu erhalten und die detaillierte Loganalyse mithilfe von exportierten Logs zu ergänzen.
Anhand der Monitoring-Diagramme können Sie Folgendes ermitteln:
- Wie schnell werden bis zur nächsten Sekunde neue Instanzen erstellt und initialisiert?
- Wie werden die Anfragen gleichmäßig auf verschiedene Instanzen verteilt?
- Wie schnell kann die Latenz bei unterschiedlichen Perzentilen auf einen stabilen Wert reduziert werden?
Sie können die Benutzeroberfläche der Google Cloud Console für BigQuery verwenden, um das exportierte Logschema und die Vorschauergebnisse zu prüfen. Führen Sie die Abfragen aus und stellen Sie die Ergebnisse mit Colab dar, das bereits in BigQuery, Pandas und Matplotlab eingebunden werden kann. Colab lässt sich auch einfach in umfangreiche Datenvisualisierungstools wie Seaborn einbinden.
Engpässe ermitteln
Mit Lasttests können Sie feststellen, ob sowohl ineffizienter Code als auch Skalierungsengpässe vorhanden sind. Ineffizienter Code führt zu höheren Kosten, da er mehr Traffic verarbeiten muss, aber nicht unbedingt Skalierungen verhindert. 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 von JMeter erfasste Logs abfragen, wobei die Logs Latenzen enthalten, die vom Client gemessen werden. 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. Vermeiden Sie übermäßige maximale Latenzen aufgrund der TLS-Verbindungsinitialisierung, die zu Ergebnissen mit Ausreißern führen kann.
Zusammenfassung der Best Practices
Führen Sie einen Lasttest durch, um festzustellen, ob die Migration zu Cloud Run die richtige Wahl ist und 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.