Lasttests in der Cloud mit Visual Studio Team Services

Article
08/28/2017

[bing_translator] Dieser Beitrag beschreibt, wie man einen Lasttest mit Visual Studio Team Services anlegt. Mit jedem Visual Studio Team Services Account kommt kostenlos ein monatliches Kontingent von 20000 “Virtual User Minutes” für Lasttests. Das Kontingent verfällt nach einem Monat, wenn es nicht genutzt wurde - es lohnt sich also Gedanken zu machen, es einfach aufzubrauchen, anstatt es verfallen zu lassen.

Es gibt mehrere Wege einen Test zu erstellen – am, einfachsten ist sicher das Erstellen in Visual Studio. Zur Ausführung in der Cloud benötigt man eine Azure Subscription und und einen Visual Studio Team Services Account.

Erstellung und Ausführung eines Lasttests mit Visual Studio

Einen Lasttest kann man am einfachsten mit Visual Studio erstellen. Dazu legt man ein Web Performance and Load Test Projekt an, Wie der Name schon sagt, gibt es hier zwei Komponenten: Webtests und Lasttests. Ein Lasttest führt einen oder mehrere Webtests in einer vorgegebenen Häufigkeit aus, um eine gewisse Last auf dem zu testenden System zu erzeugen.

Zunächst braucht man aber den Webtest. Eine *.webtest Datei exisitiert schon im Projekt, man kann beliebige weitere hinzufügen. Nach dem Öffnen des Webtests zeigt sich ein kleiner roter “Record” Knopf. Damit kann man das Mitschneiden des Netzwerkverkehrs auf dem eigenen System starten. Anschließend würde man im Internet Explorer die zu testende Website besuchen und hier beispielsweise einen bestimmten Ablauf auf dem Zielsystem ausführen (bsp. User Login, Produktsuche, Ware in Einkaufskorb legen, Ware aus Einkaufskorb entfernen, ausloggen). Den aufgezeichneten Verkehr kann man anschließend einsehen, editieren und parametrisieren. Auf diese Art wird man unnötige Requests los (bspw. Requests auf Advertising-Anbieter) und kann den Webtest flexibler machen, was die Zielsysteme angeht (indem man zum Beispiel die Zielurl als Parameter anlegt.) Die notwendigen Buttons finden sich im Menü zum Webtest.

Als zweiten Schritt würde man jetzt einen Lasttest zum gleichen Projekt hinzufügen. Das Öffnen des *.loadtest startet einen kleinen Wizard, der durch unterschiedliche Einstellungen führt – hier kann man unter anderem auswählen, welche Webtests im Rahmen des Lasttests gestartet werden sollen. Ein Lasttest ist also eigentlich nichts anderes als eine Ausführungsanweisung für andere Tests – in unserem Fall Webtests.

Eigentlich ist man jetzt schon fast am Ziel. Früher – und damit meine ich die Zeit bevor man die grandiose und komfortable Möglichkeit hatte auf Cloud-Resourcen zuzugreifen – hätte man jetzt den Lasttests direkt aus Visual Studio gestartet und auf einem lokal verfügbaren Agent, vielleicht sogar auf der eigenen Maschine gestartet.

Die Cloud bietet uns hier aber den Komfort einfach auf Agents zuzugreifen, die immer, wenn wir sie brauchen zu Verfügung gestellt werden – ohne, dass Last auf eigenen Rechnern entseht. Und für diese Agents gibt es auch das erwähnte Freikontingent.

In diesem Fall würde ich im Load Test Wizard einfach meinen Team Services Account anwählen und kann dann im zweiten Schritt das Datacenter wählen in dem mein Loadtest ausgeführt wird. An sich ist das Datacenter egal – ich kann rund um den Planeten auswählen. Standardmäßig ist das Datacenter die erste Wahl, das zum Visual Studio Team Services Account am nächsten liegt. Unter gewissen Umständen kann es aber sinnvoll sein hier explizit ein anderes auszuwählen, zum Beispiel, wenn man eine möglichst kleine oder große Distanz von Agent zur Zielapplikation haben möchte.

Zum Ausführen drückt man einfach auf “Run Load Test”. Abhängig von den gewählten Einstellungen läuft dann der Test eben lokal oder in der Cloud. Die Ergebnisse werden in beiden Fällen im Visual Studio angezeigt.

Lasttests im Azure Portal anlegen und starten

Zugegebenermaßen ist das zwar ganz nett, aber es haut einen vielleicht noch nicht um – dazu ist es zu naheliegend. Wäre es nicht schön, wenn wir derartige Loadtests auch direkt aus dem Azure Portal ausführen könnten? Von Cloud zu Cloud?

Auch diese Möglichkeit besteht. Im Azure Portal kann man für Web Apps einen Performance Test anlegen. Hier besteht die Möglichkeit entweder einzelne URLs abzufragen oder auch hier einen Webtest aus Visual Studio zu verwenden. Kleiner Hinweis: Tatsächlich wählen wir hier ein *.webstest File – nicht, wie man vielleicht meint, ein *.loadtest. Die Konfiguration der gewünschten Last erfolgt dann im Azure Portal – daduch wird dann aus dem Webtest unterm Strich ein Lasttest. Über den Menüeintrag “Set Account” legt man den VSTS Account fest, in dem die Lasttestergebnisse später sichtbar werden – so sehen alle Beteiligten, ob das System ein Problem bekommt.

Kleiner Hinweis: In diesem Fall kann als Input für die Generierung des Lasttests übrigens auch ein HTTP-Mitschnitt von Fiddler dienen – die Beschreibung dazu findet sich hier .

Die Ausführung der Tests über das Azure Portal ermöglicht es mir also völlig unabhängig von einer Entwicklungumgebung eine Aussage über das Verhalten der Anwendung unter Last zu bekommen. Spätestens jetzt sollte klar sein, dass es sich in jedem Fall lohnt das freie Lastkontingent einfach mal zu verbraten – man bekommt auf jeden Fall ein besseres Gefühl, wie sich die eigene Anwendung unter bestimmter Last verhält und man braucht noch nicht mal eigene Hardware dafür zur Verfügung zu stellen.

Lasttests und Visual Studio Team Services

In Visual Studio Team Services gibt es mehrere Möglichkeiten Lasttests anzulegen. Die offensichtliche ist es ebenso wie im Azure Portal einfach manuell einen Lasttest anzulegen. Die Benutzerführung ist hier ähnlich gehalten wie im Azure Portal. Hier finde ich auch unter “Settings” die Möglichkeit die Last des Lasttests zu konfigurieren.

Regelmäßige Lasttests nach einem Deployment

Soweit so gut – aber noch nicht gut genug. Wäre es nicht super, wenn wir derartige Lasttests regelmäßig ausführen? Zum Beispiel nach jedem erfolgten Deployment unserer Anwendung in ein bestimmtes Deployment Environment – beispielsweise das Staging System? Auf diese Weise kann man verhindern, dass man ein System öffentlich macht, das zwar “ganz gut” aussieht, aber der zu erwartenden Last nicht gewachsen wäre.

Hierzu kann ich einen Task im Release Management einbinden, der einen Lasttest ausführt. Konfiguriert wird er nach dem gleichen Schema – einfach ein *.loadtest file im Release Management und den Pfad zum Ordner mit den Testbinaries angeben. Alle Ergebnisse der Testausführung finde ich dann – wie zu erwarten – unter dem Menüpunkt Loadtest in Visual Studio Team Services.

Wieviel Kontingent habe ich noch?

Wer wissen möchte, wieviel Freikontingent noch verfügbar ist, der findet diese Info auch im Azure Portal:

Hier noch ein paar Links, die den Einstieg erleichtern:

Frohes Lasttesten!