Projektpraxis 3 – Ausführung von Leistungstestfällen

---

1. Vorbereitung der Leistungstestumgebung

1. Leistungstestumgebung: Serverkonfiguration

1. Hardwaremodell: Versuchen Sie, so konsistent wie möglich zu sein
2. Anzahl der Server:
Es können mehr als 20 Maschinen vorhanden sein Produktionsumgebung, und große Unternehmen haben sogar Tausende von Maschinen. Ist die gesamte Anzahl der Server in der Leistungstestumgebung aufgeführt? Nicht erforderlich

Benchmark-Test:
Dasselbe kann gesagt werden, und so weiter,
Zum Beispiel: 1 Maschine kann 1000/s Parallelität übertragen; theoretisch Sprichwort Dass 1.000 Maschinen eine Parallelität von 100.000/s ermöglichen können
erfordert nicht unbedingt die Anzahl der Server in der Leistungstestumgebung.

2. Datenaufbereitung

a. Reines Datenbank-SQL
b. Code zum Generieren von Daten verwenden, importierte SQL-Anweisungen: häufiger verwendet
Tipps:

Abgeleitet aus vorhandenen Daten
zufällig generiert

c. Verwenden Sie Code/Tools, um die automatische Generierung von Schnittstellen/UIs aufzurufen

Hinweise:
a. Achten Sie auf die Statusverteilung der Daten
b. Zum Beispiel Bestelldaten – mehrere Status (versuchen Sie, sie anzupassen Verteilung der Produktionsumgebung Situation)
Datenverteilung bestimmt die Leistung auf Datenbankebene
c. Extreme Datensituationen?
Leistungstests basieren auf normalen Szenarien mit einer großen Anzahl von Benutzern (Benutzer sind verstreut). Wenn das Leistungsszenario vom Geschäftsszenario getrennt ist, sind solche Leistungstests nicht erforderlich.

2. Leistungstest-Ausführungstool (Jmeter)

Version: 5.4.1
Abhängig von der Java-Umgebung: JDK1.8
Plug-in von Drittanbietern:

Legen Sie es in das folgende Verzeichnis
apache-jmeter-5.4.1\lib\ext

Thread-Modell: parallele Ausführung mit mehreren Threads
Anzahl der Threads: Wie viele virtuelle Benutzer arbeiten gleichzeitig, und der Inhalt der Arbeit ist der Inhalt in der Thread-Gruppe
Mehrere Threads werden gleichzeitig gestartet
Derselbe Thread führt die Aufgaben in der Thread-Gruppe aus: Es ist geordnet

1. Benutzerdefinierte Variablen:

2. Transaktionscontroller:

Nutzungsszenario: Wenn das von uns getestete Szenario mehrere Schnittstellen enthält, müssen Gesamtdatenstatistiken erstellt werden
Mehrere Vorgänge können als eine Transaktion gezählt werden und sind kostengünstig a>

Wenn eine Operation in der Transaktion fehlschlägt, wird der gesamte Transaktionsstatus abnormal ausgeführt. Obwohl die meisten Schnittstellen in der gesamten Transaktion keine Probleme haben, weist nur eine Schnittstelle einen Fehler auf und die Transaktionsausführung schlägt fehl.

3. Testergebnisse anzeigen

a. Zusammenfassender Bericht

Nachteile: Es können nur die Endergebnisse angezeigt werden, der Prozess ist nicht sichtbar und es ist nicht möglich zu analysieren, in welcher Phase das System den Leistungswendepunkt erreicht hat.

Etikett

Schnittstellenname

Probe

Anzahl der Schnittstellenanfragen

Durchschnitt (ms)

Nehmen Sie als Beispiel die erste Schnittstelle: Insgesamt werden 1.000 Anfragen initiiert, und jede Anfrage wird addiert und durch 1.000 dividiert, um die durchschnittliche Antwortzeit zu erhalten.

Mindestwert (ms):

Die Mindestlänge der ersten Schnittstelle beträgt 10 ms; die Mindestlänge der zweiten Schnittstelle beträgt 1 ms und so weiter.

Maximalwert (ms)

Die erste Schnittstelle hat eine maximale Länge von 115 ms, die zweite Schnittstelle hat eine maximale Länge von 15 ms und so weiter.

Standardabweichung

Gibt an, ob der Float groß ist, d. h.: der Unterschied in der Antwortzeit zwischen der ersten Anfrage, der zweiten Anfrage usw.

abnormal%

Anzahl der Schnittstellenanfragefehler/Gesamtzahl der Anfragen

Durchsatz

Die Anzahl der abgeschlossenen Anfragen pro Sekunde, der gesamte Prozess von der Ausgabe einer Anfrage durch jmeter an den Server, der die Anfrage verarbeitet und sie an jmeter zurückgibt, beträgt 1——》Geschäftsdurchsatz

Homepage-Klick auf die Hotlist-Schnittstelle, das System kann maximal 28,6 Anfragen pro Sekunde verarbeiten
Für die gesamte Transaktion kann das System maximal 19,2 Anfragen pro Sekunde verarbeiten

Der Durchsatz ist nicht in tps und qps unterteilt
tps: Datenänderungsszenario
qps: Datenabfrageszenario

KB/Sek. empfangen:

Netzwerkempfangsgeschwindigkeit——》Netzwerkdurchsatz

KB/Sek. senden:

Netzwerk-Sendegeschwindigkeit——》Netzwerkdurchsatz

Durchschnittliche Anzahl an Bytes

Netzwerkdurchsatz

b. Farbverlaufsfadengruppe

c. Grafik-Plug-in

3. Prozess der Anwendungsfallausführung

1. Benchmark-Test

Szenario 1: Online-Serverressourcenplanung
Leistungsbenchmark: Sehr wenig Parallelität zum Testen der für jeden Benutzervorgang erforderlichen Ressourcen und Leistungsindikatoren
Benchmarktest Ergebnisanalyse:

1024 KB——》1 MB
1024 MB——> 1 GB
Empfangen KB/Sek.: 3341,10 KB/Sek : bedeutet, dass die Netzwerkbandbreite 3 MB beträgt und die Parallelität 40 Anforderungen pro Sekunde erreichen kann
1. Entsprechend dem Netzwerkdurchsatz (Empfang) – wenn die Serverbandbreite keine 3 MB-Übertragung pro Sekunde unterstützen kann Da die Daten etwa 40/s betragen, kann der Server keinen Durchsatz von 40/s erreichen
2. Ein Thread simuliert 40 Parallelitäten. Wenn Sie eine Parallelität von 4000/s simulieren möchten, sind theoretisch 100 Threads erforderlich, um virtuell zu simulieren Benutzer

2. Belastungstest

Erhöhen Sie den Parallelitätsdruck des Systems kontinuierlich, bis das System unsere Leistungsanforderungen nicht mehr erfüllen kann

Reaktionszeit
Durchsatz
Ressourcennutzung

Szenario 1: Die Online-Parallelität wird voraussichtlich 4000/s erreichen. Kann das System dem standhalten?
4000/s: Wird während der Leistungsanforderungsanalyse ermittelt.
Gradientendrucktest – 》Methode

Hinweis: Wenn die Ergebnisse des Lasttests von den geschätzten Ergebnissen abweichen, passen Sie die Anzahl der Threads an
Zum Beispiel Durchsatz, theoretisch: die Systemdurchsatzkurve

a, Entladungsvolumenmodell:

Sehen Sie sich das Bankbeispiel an und vergleichen Sie die Bank mit einem Systemprojekt

Die Bank verfügt über 10 Schalterfenster (die Fenster werden nicht vergrößert, da die Systemressourcen begrenzt sind), und die Verarbeitung einer Transaktion dauert jedes Mal 1 Sekunde
Die erste Sekunde kam 1 Einzelpersonen, der Durchsatz beträgt 1
In der zweiten Sekunde kamen 5 Personen und der Durchsatz betrug 5
In der dritten Sekunde kamen 8 Personen und der Durchsatz war 8 a> In der fünften Sekunde kamen 20 Personen, und der Durchsatz betrug 10, und die restlichen Leute warteten in der Schlange in der Lobby< /span>
In der vierten Sekunde kamen 12 Personen und der Durchsatz betrug 10

20 Personen kamen in der fünften Sekunde und die ersten s wurden schnell verarbeitet. Die nächsten 10 Personen mussten 1 s auf die Verarbeitung warten -> die Antwortzeit erhöhte sich; der Durchsatz blieb gleich. Dies bedeutet nicht, dass ein Problem mit dem System vorliegt.
Die Bank verspricht, alle Anfragen innerhalb von 3 Sekunden abzuschließen. Wenn die Zeit 3 ​​Sekunden überschreitet, muss das Banksystem aktualisiert werden.

Basierend auf dem oben Gesagten: Der Durchsatz bleibt gleich, die Reaktionszeit wird sich definitiv erhöhen

erste Möglichkeit

Je mehr Leute folgten, desto mehr hatte die Bank keinen Platz zum Stehen – sie war überfüllt und es gab keine Luft zum Atmen
Schließlich hatte der Bankangestellte keine Luft zum Atmen und nur eine Bank Der Kassierer wurde ohnmächtig. , ohnmächtig 2...10, das System brach zusammen. ——》Die Luft und die Halle sind hier Systemressourcen.

Zweite Möglichkeit:

Wenn die Anzahl der Personen eine bestimmte Anzahl erreicht, schließt der Sicherheitsdienst der Bank die Tür sofort und es ist kein weiterer Zutritt mehr möglich.

Erwartetes Phänomen:
Die erste Stufe: Die Parallelität nimmt zu -> der Durchsatz wird ebenfalls zunehmen
Die zweite Stufe: Die Parallelität nimmt zu ——》 Der Durchsatz bleibt gleich und erhöht sich nicht, aber die Antwortzeit wird länger

Der Durchsatz bleibt unverändert, und es wird davon ausgegangen, dass das System ihn nicht verarbeiten kann und neue Anforderungen warten/zurückgeblieben sind (der Rückstand wird Ressourcen belegen, die Ressourcen sind begrenzt, es wird keinen unendlichen Rückstand geben und es wird schließlich abstürzen).

Die dritte Stufe – Absturz: Parallelität nimmt zu –》
1. Der Durchsatz nimmt ab,

Das System weist weiterhin Rückstände bei Anfragen auf und die Ressourcen reichen nicht aus.

2. Erhöhte Anforderungsfehlerrate

Anfrage nicht möglich, Zeitüberschreitung der Anfrage
Das System lehnt neue Anfragen ab

Benchmark-Zusammenfassungsbericht
1 Thread – „Der Durchsatz beträgt 40/Sek.

Idee: Gemäß den Benchmark-Testergebnissen während des Lasttests: Die Antwortzeit sollte mit dem Benchmark-Test übereinstimmen und der Durchsatz sollte verdoppelt werden.
Lasttest-Zusammenfassungsbericht
60 Threads——》Der Durchsatz beträgt 134/s, theoretisch 40/s*60, was nicht den idealen Punkt erreicht a>

Schlussfolgerung:
Die Schnittstelle ist langsam

4. Leistungstestbereich-Segmentierungskonzept

Benchmark: Erfassen Sie die Leistungsbasislinie des Systems in Szenarien mit extrem geringer Parallelität
Warum beträgt die Anzahl der Benchmark-Threads 1?

Anforderungen an die Anzahl der Threads: Wenn das System 100 % der Last tragen kann (es können 2 sein, es können 10 sein), ist 1 die kleinste Simulationseinheit< /font>

Auslastungstest: Der Zweck besteht darin, die tatsächliche Verarbeitungsleistung des Programmsystems zu ermitteln.
Anzahl der Auslastungstest-Threads

Wie oft kann jeder Thread laut Benchmark-Test Parallelität pro Sekunde simulieren? Im Benchmark-Test kann beispielsweise ein Thread 40/s Parallelität simulieren.
Ziel: Testen ob das System die Last 4000/s bewältigen kann
Vorläufige Anzahl der Threads = Ziel-Parallelität/Single-Thread-Simulations-Parallelitätszahl

5. Jmeter-bezogen

bedeutet, dass 100 Threads in 1 Sekunde gestartet und einmal ausgeführt werden.

Der spezifische Arbeitsinhalt ist:

3 Personen arbeiten dreimal. Haben es geschafft Insgesamt 9 Mal
Diese drei Personen haben gleichzeitig gearbeitet
Anzahl der Zyklen: Gibt an, wie oft jeder Thread arbeiten muss

jmeter-Ausführungsreihenfolge
1. Für denselben Thread sind http-Anfragen sequentiell. Führen Sie zuerst Aufgabe 1 und dann Aufgabe 2 aus

2. Wenn Es gibt drei Threads, die diese beiden Aufgaben gleichzeitig ausführen, es gibt keine Reihenfolge.
Möglicherweise hat Thread 1 Aufgabe 2 ausgeführt und Thread 2 hat mit der Ausführung von Aufgabe 1 begonnen