Hinzufügen von Lasttests zu Ihren CI-CD-Workflows in GitHub Actions

Lasttests sind eine Technik, die sich auf die Bewertung der Leistung einer Anwendung unter normalen oder erwarteten Lastbedingungen konzentriert. Das Ziel ist es, festzustellen, wie sich die Anwendung verhält, wenn sie dem erwarteten Nutzungs- und Verkehrsaufkommen ausgesetzt ist. Lasttests werden häufig eingesetzt, um zu überprüfen, ob ein System die erwartete Anzahl von Benutzern und Transaktionen bewältigen kann, und um Leistungsengpässe oder Probleme zu erkennen, die sich auf die Benutzerfreundlichkeit auswirken könnten.

Microsoft Azure bietet einen Dienst namens Azure Load Testing. Einer der Hauptvorteile dieses Dienstes ist, dass Sie die Leistung Ihrer Anwendung in großem Maßstab testen können, ohne in teure Hardware und Infrastruktur investieren zu müssen. Außerdem ist er hochgradig konfigurierbar und kann zum Testen von Anwendungen verwendet werden, die auf einer Vielzahl von Plattformen gehostet werden, darunter Azure, lokale Server und Cloud-Anbieter von Drittanbietern.

Was brauchen wir?

Zusätzlich zu einem Azure-Abonnement und einem GitHub-Konto benötigen wir ein Apache JMeter-Skript, das in der Regel aus einer Reihe von Testelementen besteht, einschließlich Thread-Gruppen, Samplern, Listenern und Assertions. Die Thread-Gruppen definieren die Anzahl und den Typ der virtuellen Benutzer, die simuliert werden sollen, während die Sampler die spezifischen Aktionen oder Anfragen definieren, die von den virtuellen Benutzern ausgeführt werden sollen. Die Listener erfassen die vom Test generierten Leistungsdaten, und die Assertions definieren die erwarteten Ergebnisse des Tests und überprüfen, ob die tatsächlichen Ergebnisse mit den Erwartungen übereinstimmen.

Hier sehen Sie ein Beispiel dafür, wie das JMeter-Skript aussieht. Sie finden dieses Skript in dem Beispielcode, den ich im Rahmen dieses Artikels erstellt habe (den Link finden Sie unten).

.

Erste Schritte

Im folgenden Beispiel werden wir Azure Load Testing in unserem GitHub Actions Workflow verwenden, um zu erkennen, wann unsere Web-App ein Leistungsproblem erreicht hat. Wir definieren ein Lasttest-Szenario mit einer bestimmten Anzahl und Art von virtuellen Benutzern, die simuliert werden sollen, sowie die Testdauer und die Art der zu simulierenden Arbeitslast, die in diesem Fall eine HTTP-Anfrage ist. Darüber hinaus können Sie entweder Visual Studio oder das Azure Portal verwenden, um Ihr Lasttest-Szenario zu erstellen und zu konfigurieren.

Sobald das Lasttest-Szenario definiert ist, können wir die Ergebnisse und die Überwachungsdaten überprüfen. Dazu gehören Metriken wie Antwortzeit, CPU-Auslastung und Netzwerkverkehr sowie benutzerdefinierte Leistungszähler, die wir definieren können. Mit diesen Daten können wir Engpässe identifizieren und die Leistung der Anwendung optimieren.

Das Szenario

Ich habe eine einfache Web-App entwickelt, die mit ASP.NET Core unter Verwendung von .NET 7 erstellt wurde. Sie verbindet sich mit einer Azure Cosmos DB und fügt einen Datensatz für jeden Besuch auf der Seite hinzu und ruft die Daten aller Besuche ab.

Hier sehen Sie einen Screenshot, wie die Anwendung aussieht:

Die Umwelt

Diese Webanwendung läuft auf einem App Service Basic-Tarif und verfügt über Applications Insights zur Überwachung der Leistung der Anwendung. Die Cosmos-DB ist auf die kostenlose Stufe eingestellt (1000 RU/s und 25 GB). Ich möchte herausfinden, ob die Anwendung, die in dieser Umgebung läuft, bis zu 100 gleichzeitige Benutzer unterstützen kann.

Hier sehen Sie einen Screenshot der Ressourcengruppe, die mit den Azure-Ressourcen für diese Anwendung erstellt wurde.

Das Repository

Sie können sich das GitHub-Repository unter diesem Link ansehen(LoadTestingDemo). Dort können Sie das Repository forken, die ARM-Vorlage verwenden, um die benötigten Azure-Dienste bereitzustellen und den Lasttest in Ihrer Umgebung durchzuführen.

Hinweis: In Microsoft Azure können Sie nur eine Cosmos DB Free Tier-Ressource pro Abonnement erstellen. Sie erhalten möglicherweise eine Fehlermeldung, wenn Sie bereits eine Cosmos DB Free Tier-Ressource in Ihrem Abonnement haben.

Dieses Repository enthält eine GitHub-Aktion, die die Anwendung erstellt und bereitstellt und den Lasttest in Azure Load Testing ausführt. Sie finden den Workflow auf der Registerkarte Aktion des Repositorys.

Hier sehen Sie einen Screenshot, der zeigt, wie die Aktion aussieht. Sie sehen, dass sie im LoadTest-Job fehlschlägt.

Die GitHub Aktion

Der Workflow besteht aus drei Schritten und wird bei jedem Push ausgeführt. In diesem ersten Schritt wird die .NET-Anwendung erstellt, im zweiten Schritt wird die Anwendung im Azure App Service bereitgestellt und im dritten Schritt wird der Lasttest-Job mit Hilfe der folgenden Dateien im Stammordner ausgeführt. Die erste Datei ist das JMeter-Skript, mit dem die Schritte des Lasttests festgelegt werden, die zweite Datei ist die Konfiguration des Lasttests.

• LoadTestingScript.jmx
• LoadTestingConfig.yaml

Die Azure-Anmeldung ist für die Kommunikation mit dem Azure Load Testing Service erforderlich, um das JMeter-Skript und die Konfiguration für den Test zu senden. In dieser Konfiguration können wir die Anzahl der Engines, mit denen wir den Test durchführen möchten, und die Fehlerkriterien festlegen. In diesem Fall ist der Schwellenwert eine durchschnittliche Antwortzeit von weniger als 5 Sekunden und ein Fehlerprozentsatz von weniger als 20%.

Die Ergebnisse

Wie Sie auf dem vorherigen Bild sehen können, ist der Lasttest fehlgeschlagen, da die durchschnittliche Antwortzeit höher war als erwartet (5 Sekunden). Im Azure-Portal erhalten Sie weitere Details über den Testlauf.

Hier sehen Sie einen Screenshot des Ergebnisses des Testlaufs im Azure-Portal.

Im Azure App Service können wir die Metriken mit den Antwortzeiten (mehr als 5 Sekunden) und die Anzahl der Anfragen mit den Dateneingängen und Datenausgängen sehen. Hier sehen Sie einen Screenshot der wichtigsten Metriken im Azure Portal:

Darüber hinaus habe ich Application Insights hinzugefügt, um die Webanwendung zu überwachen. Im Azure Portal können wir die Leistungsprobleme und -ausfälle sehen. Hier ist ein Screenshot des Leistungsbereichs für die Webanwendung:

Auf dem Bild oben können Sie sehen, woher die Anfragen kamen. In diesem Fall führe ich Azure Load Testing in der Region East US (Virginia) durch. Hier ist ein Screenshot der Ausnahme, die in der Transaktion erfasst wurde:

Fazit

Lasttests sollten nicht in einer Produktionsumgebung durchgeführt werden. Versuchen Sie es in einer Entwicklungs-/Test-, QA- oder Vorproduktionsumgebung. Auch wenn Sie auf Deployment-Slots arbeiten, denken Sie daran, dass die Webanwendung immer noch auf demselben App Service Plan läuft und dies Ihre Produktionsumgebung beeinträchtigen oder eine Denial-of-Service-Attacke verursachen könnte.

Wenn Sie mehr über Azure Load Testing erfahren möchten, empfehle ich Ihnen, sich die Dokumentation des Dienstes anzusehen .