Lasttestbeispiel mit Gatling
1. Überblick
Inprevious tutorial haben wir gesehen, wie Sie mit Gatling eine benutzerdefinierte Webanwendung testen.
In diesem Artikel verwenden wir das Gatling-Stresstool, um die Leistung der Staging-Umgebung dieser Website zu messen.
2. Das Testszenario
Lassen Sie uns zunächst unser Hauptnutzungsszenario einrichten - eines, das einem typischen Benutzer nahe kommt, der möglicherweise auf der Website surft:
-
Gehen Sie zur Homepage
-
Öffnen Sie einen Artikel von der Homepage
-
Gehen Sie zu Guides / REST
-
Gehen Sie zur Kategorie REST
-
Gehe zum vollständigen Archiv
-
Öffnen Sie einen Artikel aus dem Archiv
3. Zeichnen Sie das Szenario auf
Jetzt zeichnen wir unser Szenario mit dem Gatling-Rekorder wie folgt auf:
$GATLING_HOME/bin/recorder.sh
Und für Windows-Benutzer:
%GATLING_HOME%\bin\recorder.bat
Hinweis:GATLING_HOME ist Ihr Gatling-Installationsverzeichnis.
Es gibttwo modes for Gatling Recorder: HTTP-Proxy und HAR-Konverter.
Wir haben den HTTP-Proxy-Modus inprevious tutorial ausführlich besprochen. Schauen wir uns nun die Option HAR Converter an.
3.1. HAR-Konverter
HAR ist die Abkürzung für HTTP Archive - ein Format, das im Grunderecords the full information about a browsing session ist.
Wir können HAR-Dateien vom Browser erhalten und sie dann mit dem Gatling-Rekorder in eine Simulation konvertieren.
Wir erstellen unsere HAR-Datei mithilfe der Chrome Developer Tools:
-
Menü → Weitere Tools → Entwicklertools
-
Gehen Sie zur RegisterkarteNetwork
-
Stellen Sie sicher, dassPreserve log aktiviert ist
-
Klicken Sie nach dem Navigieren auf der Website mit der rechten Maustaste auf die Anforderungen, die Sie exportieren möchten
-
Wählen Sie dann Alle als HAR kopieren
-
Fügen Sie sie in eine Datei ein und importieren Sie sie dann vom Gatling-Rekorder
Nachdem Sie den Gatling-Rekorder nach Ihren Wünschen eingestellt haben, klicken Sie auf Start.
Beachten Sie, dass der Ausgabeordner standardmäßigGATLING_HOME/user-files-simulations ist
4. Die Simulation
Die erzeugte Simulationsdatei ist ebenfalls in Scala geschrieben. Es ist im Allgemeinen in Ordnung, aber nicht besonders gut lesbar. Daher nehmen wir einige Anpassungen vor, um es zu bereinigen. Hier ist unsere letzte Simulation:
class RestSimulation extends Simulation {
val httpProtocol = http.baseURL("http://staging.example.com")
val scn = scenario("RestSimulation")
.exec(http("home").get("/"))
.pause(23)
.exec(http("article_1").get("/spring-rest-api-metrics"))
.pause(39)
.exec(http("rest_series").get("/rest-with-spring-series"))
.pause(60)
.exec(http("rest_category").get("/category/rest/"))
.pause(26)
.exec(http("archive").get("/full_archive"))
.pause(70)
.exec(http("article_2").get("/spring-data-rest-intro"))
setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)
}
Ein wichtiger Hinweis hierbei ist, dass die vollständige Simulationsdatei viel größer ist. hier der Einfachheit halberwe didn’t include static resources.
5. Führen Sie den Lasttest aus
Jetzt können wir unsere Simulation wie folgt ausführen:
$GATLING_HOME/bin/gatling.sh
Und für Windows-Benutzer:
%GATLING_HOME%\bin\gatling.bat
Das Gatling-Tool scanntGATLING_HOME/user-files-simulations und listet alle gefundenen Simulationen auf, die wir auswählen können.
Nach dem Ausführen der Simulation sehen die Ergebnisse folgendermaßen aus:
Für einen Benutzer:
> request count 304 (OK=304 KO=0)
> min response time 75 (OK=75 KO=-)
> max response time 13745 (OK=13745 KO=-)
> mean response time 1102 (OK=1102 KO=-)
> std deviation 1728 (OK=1728 KO=-)
> response time 50th percentile 660 (OK=660 KO=-)
> response time 75th percentile 1006 (OK=1006 KO=-)
> mean requests/sec 0.53 (OK=0.53 KO=-)
---- Response Time Distribution ------------------------------------
> t < 800 ms 183 ( 60%)
> 800 ms < t < 1200 ms 54 ( 18%)
> t > 1200 ms 67 ( 22%)
> failed 0 ( 0%)
Für 5 gleichzeitige Benutzer:
> request count 1520 (OK=1520 KO=0)
> min response time 70 (OK=70 KO=-)
> max response time 30289 (OK=30289 KO=-)
> mean response time 1248 (OK=1248 KO=-)
> std deviation 2079 (OK=2079 KO=-)
> response time 50th percentile 504 (OK=504 KO=-)
> response time 75th percentile 1440 (OK=1440 KO=-)
> mean requests/sec 2.411 (OK=2.411 KO=-)
---- Response Time Distribution ------------------------------------
> t < 800 ms 943 ( 62%)
> 800 ms < t < 1200 ms 138 ( 9%)
> t > 1200 ms 439 ( 29%)
> failed 0 ( 0%)
Für 10 gleichzeitige Benutzer:
> request count 3058 (OK=3018 KO=40)
> min response time 0 (OK=69 KO=0)
> max response time 44916 (OK=44916 KO=30094)
> mean response time 2193 (OK=2063 KO=11996)
> std deviation 4185 (OK=3953 KO=7888)
> response time 50th percentile 506 (OK=494 KO=13670)
> response time 75th percentile 2035 (OK=1976 KO=15835)
> mean requests/sec 3.208 (OK=3.166 KO=0.042)
---- Response Time Distribution ----------------------------------------
> t < 800 ms 1752 ( 57%)
> 800 ms < t < 1200 ms 220 ( 7%)
> t > 1200 ms 1046 ( 34%)
> failed 40 ( 1%)
Beachten Sie, dass einige der Anforderungen beim Testen von 10 gleichzeitigen Benutzern fehlgeschlagen sind - einfach, weil die Staging-Umgebung diese Art von Last nicht verarbeiten kann.
6. Fazit
In diesem kurzen Artikel haben wir die HAR-Option zum Aufzeichnen von Testszenarien in Gatling untersucht und einen einfachen ersten Test von example.com durchgeführt.