Load Testing Baeldung with Gatling

1. Overview

In the previous tutorial, we’ve seen how to use Gatling to load test a custom web application.

In this article we’ll make use the Gatling stress tool to measure the performance of the staging environment of this website.

2. The Test Scenario

Let’s first set up our main usage scenario – one that comes close to a typical user that might be browsing the site:

1. Go to the Home Page
2. Open an Article from Home Page
3. Go to Guides/REST
4. Go to the REST Category
5. Go to the Full Archive
6. Open an Article from the Archive

3. Record the Scenario

Now, we’ll record our scenario using the Gatling recorder – as follows:

$GATLING_HOME/bin/recorder.sh

And for Windows users:

%GATLING_HOME%\bin\recorder.bat

Note: GATLING_HOME is your Gatling installation directory.

There are two modes for Gatling Recorder: HTTP Proxy and HAR Converter.

We discussed the HTTP Proxy mode in detail in the previous tutorial – so let’s now have a look at the HAR Converter option.

3.1. HAR Converter

HAR is short for HTTP Archive – which is a format that basically records the full information about a browsing session.

We can obtain HAR files from the browser then use the Gatling Recorder to convert it into a Simulation.

We’ll create our HAR file with the help of the Chrome Developer Tools:

• Menu -> More Tools -> Developer Tools
• Go to Network Tab
• Make sure Preserve log is checked
• After you finish navigating the website, right click on the requests you want to export
• Then, select Copy All as HAR
• Paste them in a file, then import it from the Gatling recorder

After you finish adjusting Gatling recorder to your preference, Click start.

Note that the output folder is by default GATLING_HOME/user-files-simulations

4. The Simulation

The generated simulation file is similarly written in Scala. It’s generally OK, but not super readable, so we’ll do some adjustments to clean up. Here is our final Simulation:

class RestSimulation extends Simulation {

    val httpProtocol = http.baseURL("http://staging.baeldung.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)
}

An important note here is that the full simulation file is much larger; here, we didn’t include static resources for simplicity.

5. Run the Load Test

Now, we can run our simulation – as follows:

$GATLING_HOME/bin/gatling.sh

And for Windows users:

%GATLING_HOME%\bin\gatling.bat

The Gatling tool will scan GATLING_HOME/user-files-simulations and list all found simulations for us to choose.

After running the simulation here’s what the results look like:

For one user:

> 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%)

For 5 simultaneous users:

> 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%)

For 10 simultaneous users:

> 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%)

Note that some of the requests failed when tested 10 simultaneous users – simply because the staging environment isn’t capable of handling that kind of load.

6. Conclusion

In this quick article we explored the HAR option of recording test scenarios in Gatling as well as did a simple initial test of baeldung.com.