Lasttests in der Azure-Cloud. Wie teste ich einen großen Online-Shop unter realen Bedingungen?

In diesem Artikel werden wir unsere eigenen praktischen Erfahrungen teilen, die wir beim Testen der Web Apps-Anwendung (Online-Shop) in der MS Azure-Cloud gesammelt haben, und beschreiben, welche Tools wir zur Lösung dieses Problems verwendet haben und welche Schlussfolgerungen auf der Grundlage der Ergebnisse gezogen wurden Ergebnisse.


Testobjekt


Wir haben VirtoCommerce Storefront (eine Webanwendung, die als Front-End für Anwendungen verwendet wird, die auf der VirtoCommerce-Plattform erstellt wurden) als Testobjekte ausgewählt.

Um ein reales Bild der Systemfunktionen zu erhalten, müssen Benutzeranforderungen so realitätsnah wie möglich simuliert werden. Es macht keinen Sinn, die Hauptseite zu überprüfen, die sich möglicherweise im Cache befindet, und dann zu behaupten, dass unsere Geschwindigkeit 1k req / sec betrug. Eine solche Leistungsmetrik macht im wirklichen Leben keinen Sinn.

Damit unsere Testergebnisse statistisch signifikant sind und die Leistungsindikatoren für den realen Verkehr so ​​genau wie möglich widerspiegeln, wurde beschlossen, Abfragen zu verwenden, die dem tatsächlichen Benutzerverhalten im Online-Shop so nahe wie möglich kommen.

Lassen Sie uns auf die folgenden Aktionen eingehen, aus denen unser "echter" Test bestehen wird:

Benutzeraktion (Testtyp)


Prozentsatz aller Anfragen


Zeigen Sie eine einzigartige Kategorieseite mit ihren Produkten an


30%


Zeigen Sie eine einzigartige Produktkarte an


40%


Artikel in den Warenkorb legen


10%


Suchen Sie nach Produkten anhand eines eindeutigen Schlüsselworts oder Attributs


20%



Abb. 1. Die Hauptaktionen der Benutzer und ihre spezifische Nutzungshäufigkeit.

Vorbereitung der Testdaten


Die wichtigste Phase für jeden Test ist die Datenaufbereitung. Testdaten sollten so ausgewählt werden, dass sie möglichst quantitativ und qualitativ (Kommunikation, Struktur usw.) den Daten in einem realen System entsprechen. Wenn möglich, sollte die Gesamtdatenmenge ausreichend sein, damit beim Testen möglichst wenige wiederholte Aufrufe derselben Daten erfolgen, wodurch eine häufige Verwendung des Caches vermieden wird und das pessimistischste Bild der Systemleistung erhalten wird.

Die wichtigsten Daten für den Online-Shop sind in der Regel: ein Katalog von Produkten und Kategorien mit Preisen, Rabatten und Informationen zu Salden.

Als Füllung für die Testumgebung wurden echte Katalogdaten verwendet, die in der Hauptproduktionsumgebung verwendet werden:


Abb. 2. Daten, die zum Auffüllen des zu testenden Systems verwendet werden.

Es ist klar, dass für einen Leser, der mit der Struktur des VirtoCommerce-Katalogs nicht vertraut ist, einige Datentypen möglicherweise nichts bedeuten, aber wir werden sie dennoch präsentieren, um zumindest eine Vorstellung von der quantitativen Reihenfolge zu haben.

Projektvorbereitungs- und Aufzeichnungstests


Als Hauptwerkzeug für Lasttests verwenden wir MS Visual Studio Enterprise 2017 (in anderen Editionen der Studio-Unterstützung für diesen Projekttyp möglicherweise nicht verfügbar) und den Projekttyp Webleistungs- und Lasttestprojekt .


Abb. 3. Erstellen Sie ein neues Projekt.

Nach dem Erstellen des Projekts müssen wir Tests für jede der zuvor definierten Benutzeraktionen erstellen. Wir beschränken uns darauf, einen Test für eine Benutzeraktion als Beispiel zu erstellen, da der Rest der Aktionen analog erstellt wird.

Für Tests verwenden wir den in Visual Studio integrierten Standardtesttyp Web Performance Test.

Unser erster Test, den wir erstellen, wird ein Test sein, der Produktdetails in einem Online-Shop enthüllt.

Um einen Test zu erstellen, wählen Sie den Testtyp „ Web Performance Test“ aus der von Studio angebotenen Liste aus und setzen Sie den Namen „Storefront-ProductDetail“ .


Abb. 4. Auswählen eines Testtyps in Visual Studio.

Für diese Art von Test versucht Visual Studio sofort, einen Browser zu öffnen, in dem Sie interaktiv auf die erforderlichen Aktionen direkt auf der Site klicken können. Wir werden dies jedoch nicht tun, sondern den Browser sofort schließen und die Aufzeichnung beenden. Als Ergebnis erhalten wir einen leeren Storefront-ProductDetail.webtest- Test.

Als Nächstes müssen wir eine Datenquelle für diesen Test hinzufügen, um verschiedene Abfrageparameter innerhalb desselben Tests verwenden zu können. Dazu bietet der V S Studio-Webleistungstest eine solche Möglichkeit.

Als Datenquelle für unseren Test verwenden wir eine Tabelle in der Datenbank, in der Produktdatensätze gespeichert sind. Danach können wir die Daten aus der verbundenen Quelle in der Anfrage verwenden, wodurch die Produktdetails der getesteten Anwendung geöffnet werden sollen. Dies wird durch Einfügen der Konstruktion "{{Datenquellenname. Tabellenname. Spaltenname}}" erreicht.

Infolgedessen wird unser erster Test nach allen Manipulationen diese Form annehmen.


Abb. 5. Inhalt des Tests

Es ist Zeit für den ersten Lauf. Versuchen Sie, unseren Test auszuführen, und stellen Sie sicher, dass er ordnungsgemäß funktioniert.


Abb. 6. Das Ergebnis eines einzelnen Tests

In Analogie werden wir Tests für alle unsere anderen Szenarien erstellen.


Abb. 7. Die resultierende Testsuite

Danach ist fast alles bereit, um einen kombinierten Test zu erstellen, der das tatsächliche Verhalten des Benutzers auf der Site emuliert.

Fügen Sie dazu unserem Projekt einen neuen LoadTest hinzu.


Abb. 8. Erstellen Sie einen neuen Belastungstest

Wählen Sie im angezeigten Assistenten den Typ Lokaler Lasttest aus .


Abb. 9. Auswahl eines Testtyps

Dieser Punkt bedarf einiger Klarstellung, da Sie zu Recht fragen: "Und was vor Ort?" In diesem Artikel geht es um das Testen mit Teams Services und MS Azure. Da wir jedoch Datenquellen in Form von Tabellen oder anderen externen Diensten für Tests verwenden, kann dies zu Schwierigkeiten führen, wenn wir versuchen, diesen Test in der Cloud auszuführen.

Nach vergeblichen Versuchen, solche Tests in der Cloud zum Laufen zu bringen, haben wir dieses Unternehmen aufgegeben und beschlossen, die sogenannten "aufgezeichneten" Tests zum Testen zu verwenden, die durch Aufzeichnen von Abfragen erhalten werden, die durch lokal ausgeführte Tests generiert und mit Datenquellen verbunden wurden.

Zum Aufzeichnen von Tests verwenden wir Fiddler, mit dem Anforderungen in das Visual Studio-Webtestformat exportiert werden können. Ein wenig weiter werden wir das Verfahren zur Aufzeichnung eines solchen Tests detaillierter beschreiben.

In den nächsten Schritten wählen wir die Dauer des Tests, die Anzahl der Benutzer und vor allem aus, aus welchen Tests unser MixedLoadTest bestehen soll und in welchen Anteilen sie verwendet werden.


Abb. 10. Komponenten testen

Als Ergebnis erhalten wir nach allen Aktionen einen kombinierten MixedLoadTest , der für die Ausführung für eine lokal bereitgestellte Anwendung konfiguriert ist.
Als nächstes müssen wir diesen Test ausführen und versuchen, mit Fiddler alle Anforderungen aufzuzeichnen, die als Ergebnis des Tests generiert werden, sowie einen „Datensatz“ zu erhalten, den wir direkt in der Cloud ausführen können.

Führen Sie zuerst Fiddler und unseren MixedLoadTest- Test aus.


Abb. 11. Das Ergebnis des Tests

Nachdem wir alle Daten verarbeitet haben, erhalten wir dieses Bild in Fiddler


Abb. 12. Testsitzung bei Fiddler

Als Nächstes speichern wir in Fiddler alle Sitzungen im Format Visual Studio-Webtests , Datei -> Sitzungen exportieren -> Alle Sitzungen -> Visual Studio-Webtests und fügen die resultierende Datei dem Projekt hinzu. Ich möchte Sie daran erinnern, dass diese Aktion erforderlich ist, damit wir den Test ohne Bezugnahme auf externe Datenquellen erhalten können, da das Starten dieser Art von Tests Probleme in der Cloud verursachen kann.


Abb. 13. Details des „aufgezeichneten“ Tests

Jetzt ist fast alles bereit, um unseren Test in der Cloud auszuführen. Der letzte Schritt bei der Vorbereitung des Tests besteht darin, den „aufgezeichneten“ MixedLoadTest in einem beliebigen Texteditor zu öffnen und localhost : 8888 (Proxy-Adresse, Fiddler) durch die Adresse unseres Geschäfts in der Cloud zu ersetzen.

Ausführen eines Tests in der Cloud


Um die Tests in der Cloud auszuführen, benötigen wir ein gültiges Konto in Visual Studio Team Services .

Erstellen Sie einen neuen LoadTest. Wählen Sie diesmal nur Cloud-basierten Lasttest mit Visual Studio Team Services aus .



In den nächsten Schritten wählen wir das Rechenzentrum aus, aus dem Datenverkehr zur getesteten Ressource generiert wird, sowie die maximale Anzahl von Agenten (Benutzern) für das konstante Muster, oder wenn wir die Last schrittweise erhöhen möchten, müssen wir die entsprechenden Parameter festlegen.



Bei der Auswahl der Tests wählen wir den einzigen Test aus, den wir zuvor mit Fiddler aufgezeichnet haben. Er emuliert die „echte“ Belastung der getesteten Ressource.



Nach Abschluss der Erstellung starten wir einen Test, bei dem das Studio einige wichtige Metriken wie Leistung und Bandbreite anzeigt sowie Echtzeitdiagramme erstellt.


Abb. 14. Der Vorgang zum Ausführen des Tests in der Cloud

Nach Abschluss des Tests können Sie den gespeicherten Webbericht auch in VSTS anzeigen:



Abb. 15. Webbericht im Visual Studio Team Services-Portal

Ergebnisanalyse


Der wichtigste Punkt ist die Verarbeitung und Analyse der Testergebnisse. Für die betreffende Aufgabe musste die Leistung einer Anwendung bewertet werden, die auf verschiedenen Konfigurationen von Azure Web Apps B2- und B3-Tarifen ausgeführt wird.

Zu diesem Zweck haben wir den Test „Aufgezeichnet“ für die Anwendung in verschiedenen Konfigurationen erneut ausgeführt und die Ergebnisse in einem Excel-Dokument aufgezeichnet.

Als Ergebnis haben wir diesen Bericht erhalten:


Abb.16. Testergebnisbericht

Nach der Analyse der erhaltenen Daten konnte die maximale Belastung ermittelt werden, der unsere Anwendung standhalten kann - es sind etwa 60 gleichzeitige Benutzer oder 9 Anforderungen / Sek. mit einer durchschnittlichen Seitenrücklaufzeit von 2,5 Sekunden. Die Grafik zeigt, dass Leistungsprobleme nach einem bestimmten Schwellenwert für die Anzahl der Anforderungen abrupt beginnen.

Wie sich später herausstellte, war der Grund dafür eine Prozessorlast von 100%, da wir eine Bibliothek eines Drittanbieters für das Rendern von Serverseiten verwendeten, bei der reguläre Ausdrücke zum Tokenisieren und Analysieren von Markups verwendet wurden.

Schlussfolgerungen


Die Produktivität einer sich aktiv entwickelnden Anwendung neigt immer sehr stark zur Verschlechterung, da jede Änderung, selbst die aus Sicht des Entwicklers unbedeutendste, zu dramatischen Konsequenzen für die Anwendungsleistung führen kann. In diesem Zusammenhang ist die regelmäßige Leistungsprüfung ein wichtiges Verfahren, das regelmäßig durchgeführt werden und Teil der Prozesse der kontinuierlichen Integration sein sollte.

Das Projekt selbst und die als Ergebnis der Tests erhaltenen Berichte sind auf GitHub verfügbar .

Source: https://habr.com/ru/post/de412947/


All Articles