Lade Testmeldung mit Gatling

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:

  1. Gehen Sie zur Homepage

  2. Öffnen Sie einen Artikel von der Homepage

  3. Gehen Sie zu Guides / REST

  4. Gehen Sie zur Kategorie REST

  5. Gehe zum vollständigen Archiv

  6. Ö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.