Analyse der Stresstestergebnisse

Jeden Tag auf der Welt gibt es immer mehr Werkzeuge, um Stresstests durchzuführen. Tatsächlich beginnt das Interesse an diesem Thema zu wachsen.

Die Hauptaufgabe eines Lasttest-Tools besteht darin, eine bestimmte Last auf das System aufzubringen. Abgesehen davon gibt es noch eine weitere, nicht weniger wichtige Aufgabe - einen Bericht über die Ergebnisse der Übermittlung dieser Last zu erstellen. Andernfalls werden wir Tests durchführen, aber wir können nichts über das Ergebnis sagen und wir können nicht genau bestimmen, ab welchem ​​Zeitpunkt die Verschlechterung des Systems begann.



Die derzeit beliebtesten Testwerkzeuge sind Gatling, MF LoadRunner und Apache JMeter. Alle haben die Möglichkeit, vorgefertigte Berichte über die durchgeführten Tests sowie einzelne Diagramme oder Rohdaten zu erstellen, auf deren Grundlage der Bericht selbst erstellt wird.







Bevor Sie einen Bericht schreiben, müssen Sie verstehen, für wen wir ihn schreiben und welchen Zweck wir verfolgen. Es macht keinen Sinn, dem Bericht für jeden Vorgang viele Diagramme der Anwendungsantwortzeit hinzuzufügen, wenn Sie feststellen möchten, ob Speicherlecks vorliegen, ob während eines Zuverlässigkeitstests instabile Arbeit behoben wurde oder ob Sie im Rahmen von Regressionstests zwei Releases miteinander vergleichen müssen. Um diese Fragen zu beantworten, benötigen Sie nur ein paar Grafiken, es sei denn, Sie haben die Probleme behoben und möchten sie nicht verstehen. Überlegen Sie sich daher vor dem Erstellen eines Berichts, ob Sie wirklich alle oder nur die indikativsten Diagramme hinzufügen müssen, und geben Sie eine Antwort auf den Testzweck. Der Satz von Diagrammen und ihre Analyse für den Bericht hängen auch vom ausgewählten Lastmodell ab - geschlossen oder offen,da verschiedene Modelle unterschiedliche Zahlen in den Diagrammen ergeben.



Wir bei Tinkoff verwenden das Gatling-Tool aktiv. Daher zeigen wir Ihnen am Beispiel, wie Sie einen Bericht über Ihre Träume erstellen und wo Sie bei der Analyse darauf achten müssen. Ich möchte auch sofort darauf hinweisen, dass fast alle im Artikel beschriebenen Diagramme online mit einem Bundle Ihres Tools mit Grafana abgerufen werden können. Es ist das bequemste Tool zum Erstellen von Berichten im laufenden Betrieb mithilfe eines vorkonfigurierten Dashboards. Darüber hinaus können Sie fast jedes Diagramm basierend auf den von Ihnen gesendeten Daten schneller erstellen. Für fast alle Lasttest-Tools gibt es bereits vorgefertigte Dashboards. Es werden auch Diagramme für andere Tools - MF LoadRunner und Apache JMeter - gegeben, deren Analyse in Analogie zu Gatling erstellt wird.

Grundlegende Metriken

Indikatoren

Zeigt die quantitative und prozentuale Verteilung der Antwortzeit der Anforderung nach Gruppe an. Diagramme dieses Typs sind praktisch, um eine schnelle vorläufige Bewertung der Testergebnisse ohne eine eingehendere Analyse der übrigen Diagramme zu ermöglichen.



Schwellenwerte von Gruppe zu Gruppe werden basierend auf Peer Review oder SLA (nicht funktionale Anforderungen) vordefiniert. Beispielsweise kann es drei Gruppen geben:

• ausgezeichnet - Reaktionszeit weniger als 50 Sekunden;
• mittel - mehr als 50, aber weniger als 100 Sekunden;
• schrecklich - über 100 Sekunden.

In Gatling können Sie selbst die Schwellenwerte für den Wechsel von Gruppe zu Gruppe und deren Anzahl in der Datei gatling.conf konfigurieren. Es ist besser, Diagramme dieses Typs basierend auf der Methodik zu erstellen. APDEX (Application Performance Index)

Sie können auch einen Indikator mit der Anzahl / dem Prozentsatz fehlgeschlagener Anforderungen hinzufügen.







Mit der APDEX-Methode können Sie Indikatoren in Regressionstests verwenden, um Releases zu vergleichen: Auf diese Weise können Sie sofort erkennen, wie viel schlechter oder besser das Release im Allgemeinen geworden ist. Leider ist dieses Diagramm in MF LoadRunner und Apache JMeter nicht sofort einsatzbereit, aber es ist einfach, es mit dem Grafana-Dashboard zu erstellen.

Antwortzeitplan

Standardmäßig erstellt Gatling eine Tabelle basierend auf Perzentilen, durchschnittlichen und maximalen Antwortzeiten und Fehlern. Es verfolgt das Überschreiten des SLA (Überschuss an nicht funktionalen Anforderungen). In der Regel gibt die SLA die Perzentile 95, 99 und den Prozentsatz der Fehler an. Auf diese Weise können Sie anhand der Tabelle schnell die Testergebnisse beurteilen.



Wenn Sie Abfragen als Transaktionen gruppieren, sehen Sie in der Tabelle sowohl die Bewertung für einzelne Abfragen als auch die Bewertung für die gesamte Gruppe und Transaktion gleichzeitig.

Diagramm der virtuellen Benutzer

Wird normalerweise in Teilen gemessen und zeigt, wie Benutzer in die Anwendung eintreten, wodurch das tatsächliche Lastprofil veranschaulicht wird. Es sollte sofort beachtet werden, dass diese Diagramme für MF LoadRunner und Gatling die Anzahl der virtuellen Benutzer und für Apache JMeter die Anzahl der Threads anzeigen.



Das Diagramm dient zur Kontrolle der Richtigkeit der Lastanwendung. Es ist erforderlich, dass Ihr Entwurfsszenario dem entspricht, was Sie in der Realität an das System übermittelt haben. Wenn Sie beispielsweise im Diagramm große Abweichungen vom geplanten Szenario nach oben sehen, ist ein Fehler aufgetreten: Ein Fehler in der Berechnung, mehr Kopien des Ladewerkzeugs wurden als erforderlich gestartet usw. Möglicherweise macht es keinen Sinn, weitere Diagramme zu analysieren, da Sie 100 Benutzer mehr als geplant übermittelt haben und das System ursprünglich für die Verwendung mit nur 10 Benutzern konzipiert wurde.

Dieses Diagramm ist in zwei Typen unterteilt:

• Aktive Benutzer zeigt an, wie viele Threads derzeit pro Sekunde aktiv sind. Wenn Gewinde starten und stoppen, insbesondere in einem Modell mit offener Last, schwankt diese Rate während des Tests.
• Total VUsers zeigt an, wie viele Threads seit Beginn des Tests insgesamt gestartet und gestoppt wurden. Praktisch für ein Modell mit geschlossener Last, bei dem die Gewinde nicht absterben.

Der Typ des Diagramms hängt auch vom Lastmodell ab:

• Geschlossenes Modell - Benutzer müssen sich gemäß dem geplanten Lastprofil beim System anmelden. Wenn die Grafik Einbrüche oder Spitzen zeigt, bedeutet dies, dass die Last nicht dem berechneten oder geplanten Szenario entsprach und weitere Untersuchungen erforderlich sind.
• — , . , . , , / . , — .

Response Time

Am häufigsten in Millisekunden gemessen - zeigt die Antwortzeit auf Anforderungen an die Anwendung an. Die Antwortzeit sollte die SLA nicht überschreiten. Dieses Diagramm ist das Hauptwerkzeug zum Auffinden von Verschlechterungspunkten während des Belastungstests.



Wenn Peaks in der Grafik sichtbar sind, bedeutet dies, dass die Anwendung zu diesem Zeitpunkt aus irgendeinem Grund nicht reagiert hat - dies kann ein Ausgangspunkt für weitere Untersuchungen sein. Die Reaktionszeit sollte gleichmäßig sein, ohne Spitzen für alle Vorgänge während des gesamten Lastschritts und auch mit dem Mitreißen der Last korrelieren. Gatling enthält im Gegensatz zu anderen Tools kein Diagramm der Netto-Antwortzeiten (durchschnittlich, nicht aggregiert).



Zusätzlich zum Diagramm der Antwortzeit jeder Anforderung ist es zweckmäßig, eine Zeile mit der Gesamtantwortzeit (Gesamtantwortzeit) anzuzeigen. Durch Überlagern des Diagramms der angelegten Last (VU / RPS) können Sie die Korrelation mit zunehmender Reaktionszeit aufgrund der zunehmenden angelegten Last (VU / RPS) verfolgen. Apache JMeter nennt dieses Diagramm Response Times vs Threads.



Als nächstes werden Diagramme angezeigt, auf denen sich viele Linien befinden können, von denen jede ihr eigenes Szenario oder ihre eigene Anforderung anzeigt. Wenn Sie einen komplexen Test mit vielen Operationen und einem nichtlinearen Profil haben, empfehlen wir, dass Sie nur die repräsentativsten Abfragen oder Gruppen von Abfragen im Bericht anzeigen. Alternativ können Sie nur Anforderungen widerspiegeln, die das SLA / SLO überschreiten, um den Zeitplan und den Bericht nicht zu überladen.

Diagrammvariationen

Eine Änderung ist möglich, bei der die Perzentile der Antwortzeit angewendet werden und eine Zeile der durchschnittlichen Antwortzeit für alle Anforderungen hinzugefügt wird. Die Verwendung von Perzentilen ist hier korrekter, da die durchschnittliche Antwortzeit sehr empfindlich auf scharfe Ausreißer reagiert.



Bei Leistungstests werden aus Gründen der Übersichtlichkeit am häufigsten das 95. und das 99. Perzentil verwendet. Wenn Sie jedoch die durchschnittliche Antwortzeit betrachten, sollten Sie dabei die Standardabweichung berücksichtigen.

Verteilung der Reaktionszeit

Es gibt auch hervorragende Diagramme, die die Abhängigkeit der Zeitverteilung von der Anzahl der Anforderungen zeigen.



Diese Art von Diagrammen ähnelt Indikatoren, zeigt jedoch ein vollständigeres Bild der Zeitverteilung, ohne durch Perzentile oder andere Aggregate abgeschnitten zu werden. Mithilfe des Diagramms können Sie die Grenzen für Gruppen von Indikatoren klarer definieren. MF LoadRunner hat keinen solchen Zeitplan.

Latency

Aus dieser Metrik kann auch ein zusätzlicher Parameter Latenz (Millisekunden) unterschieden werden - die Latenzzeit (meistens wird dies als Netzwerklatenz verstanden). Dieser Parameter zeigt die Zeit zwischen dem Ende des Anforderungsversands bis zum Empfang des ersten Antwortpakets vom System an.

Mit diesem Parameter können Sie auch die Latenz auf Netzwerkebene messen, wenn der Parameter wächst. Es ist wünschenswert, dass es gegen Null tendiert. Dieser und der nächste Diagrammtyp werden hauptsächlich zur eingehenden Analyse und zum Auffinden von Leistungsproblemen verwendet. Dieses Diagramm ist in Gatling nicht sofort einsatzbereit. In MF LoadRunner wird dieses Diagramm im Block "Netzwerkvirtualisierungsdiagramme" als Diagramm für durchschnittliche Latenz bezeichnet, wenn Sie Überwachungsagenten installiert haben.

Bandbreite

Ähnlich wie in der obigen Metrik können Sie den Parameter Bandbreite (Kilobit pro Sekunde) auswählen - die Kanalbandbreite. Es zeigt die maximale Datenmenge, die pro Zeiteinheit übertragen werden kann.



Durch Ändern dieses Parameters im Ladewerkzeug können Sie verschiedene Verbindungsquellen zur Anwendung simulieren: 4G-Mobilfunknetz oder kabelgebundenes Netzwerk. Die kostenlose Version von Gatling verfügt nicht über dieses Diagramm, sondern ist nur in der kostenpflichtigen Version von Gatling FrontLine verfügbar. Dieses Diagramm ist nur in MF LoadRunner sofort einsatzbereit. Es befindet sich im selben Block wie die Latenz und wird als Diagramm zur durchschnittlichen Bandbreitennutzung bezeichnet.

Diagramm "Anfrage pro Sekunde"

Gemessen in Stücken pro Sekunde - Zeigt die Anzahl der Anforderungen an, die in 1 Sekunde in das System eingehen.



Das Diagramm zeigt, wie viele Anforderungen Ihr System unter Last verarbeiten kann, und es ist auch das Hauptdiagramm zum Erstellen des Berichts. Es werden auch Spuren verfolgt, die über die SLA hinausgehen, da mit einer Zunahme der Last beim Passieren des Verschlechterungspunkts oder lokaler Extrema ein Fehler und dann ein starker Anstieg beobachtet werden kann. Meistens ist dies auf die Tatsache zurückzuführen, dass sich zu Beginn der Verschlechterung der Anwendung auch Anforderungen am Eingang der Anwendung ansammeln (eine Warteschlange wird angezeigt). Die Anwendung gibt ihnen dann eine Antwort oder Anforderungen fallen durch Zeitüberschreitung ab, was zu einer starken Zunahme des Diagramms führt. weil die Antwort erhalten wurde.

1. VU, RPS/TPS , .
2. Response Time, , .

TPS

Es wird in Stücken pro Sekunde gemessen und zeigt die Anzahl der Transaktionen (es können viele Anforderungen innerhalb einer Transaktion sein) in 1 Sekunde an.



Zum Beispiel umfasst die Transaktion "Eingabe Ihres persönlichen Kontos" die folgenden Anforderungen: Öffnen der Hauptseite, Eingabe eines Logins, Passworts, Drücken der Schaltfläche "Senden", Weiterleiten zur Begrüßungsseite - pro Zeiteinheit. In Gatling kann ein Diagramm nur mit Grafana abgerufen werden, da für Gruppen im HTML-Bericht Diagramme nur nach Antwortzeit erstellt werden.

Fehlerdiagramm

Normalerweise gemessen in der Rate (Stück pro Sekunde) - die Grafik zeigt die Zunahme der Anzahl fehlerhafter Anfragen. Es ist auch praktisch, den Wert als Prozentsatz der Gesamtzahl der Anforderungen zu messen. In diesem Diagramm wird die SLA außerhalb der Grenzen anhand der Anzahl oder des Prozentsatzes der Fehler verfolgt.



Wenn Sie das Diagramm "Antwortzeit" überlagern, können Sie sehen, wie sich eine Zunahme der Fehler auf eine Zunahme der Antwortzeit der Anwendung auswirkt.



Gatling hat standardmäßig kein separates Diagramm, das nur Fehler anzeigt. In Gatling wird es mit dem VU-Diagramm kombiniert und zeigt sofort, wie sich eine Zunahme der Last auf eine Zunahme der Anzahl von Fehlern auswirkt, und hilft dabei, den Schwellenwert zu erkennen, ab dem die SLA überschritten wird oder überhaupt Fehler auftreten. Apache JMeter hat auch keinen separaten Zeitplan, sondern wird mit den Diagrammen der Anzahl der Transaktionen kombiniert.

HTTP-Antwortstatus

Es ist auch möglich, die Verteilung der Anzahl von Fehlern durch Anwendungsantwortcodes in einem Diagramm darzustellen - es ist praktisch, um Fehler zu klassifizieren.



Wenn Sie beispielsweise im vorherigen Diagramm 100% erhalten haben, beginnen Sie zu analysieren, welche 50-fachen Fehler darauf zurückzuführen sind, dass der Server nicht reagiert, oder welche 403-Fehler auf den falschen Pool zurückzuführen sind und Benutzer sich nicht anmelden können, wenn beispielsweise Sie verwenden das HTTP-Protokoll.

Die kostenlose Version von Gatling verfügt zunächst nicht über dieses Diagramm, sondern ist nur in der kostenpflichtigen Version von Gatling FrontLine verfügbar. Damit das Diagramm in der kostenlosen Version angezeigt wird, müssen Sie die Datei logback.xml neu konfigurieren, damit die Protokolle im Graylog erfasst werden, und das gewünschte Diagramm darin erstellen.

Durchsatzdiagramm

Sie wird normalerweise in Bit pro Sekunde gemessen. Die Grafik zeigt den Durchsatz der Anwendung, nämlich wie viele Daten von der Anwendung pro Zeiteinheit gesendet und verarbeitet wurden.

Es wird normalerweise zur eingehenden Analyse eines Anwendungsproblems verwendet. Gatling enthält dieses Diagramm nur in FrontLine, nicht in der kostenlosen Version.

Mögliche Änderungen

1. Response Time, , (Throughput). Response Time, Throughput , : - .
2. Bandwidth, , .
3. VU, , , . .

Die meisten Diagramme können nach dem Test mithilfe der HTML-basierten Gatling-Berichte oder durch Konfigurieren des Graphite-InfluxDB-Grafana- Überwachungspakets abgerufen werden . Für die Anzeige können Sie ein vorgefertigtes Dashboard aus der Dashboard-Bibliothek https://grafana.com/grafana/dashboards/9935 verwenden .



Beachten Sie beim Analysieren und Kompilieren Ihrer Dashboards für Gatling, dass die Ergebnisse in InfluxDB aggregiert gespeichert werden und nur für die vorläufige Auswertung von NT-Ergebnissen geeignet sind. Es wird empfohlen, nach dem Test das simulations.log erneut in die Datenbank zu laden, einen Abschlussbericht darüber zu erstellen und nach Systemleistungsproblemen zu suchen.

Matrixbeschreibung von Metriken

Alles, was wir oben beschrieben haben, wird in Form einer kleinen Tafel dargestellt, die all dieses Wissen zusammenfasst.