Load Testing Baeldung with Gatling

Refactor Java code safely — and automatically — with OpenRewrite.

Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.

Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.

Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.

Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.

Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.

In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:

>> Flexible Pub/Sub Messaging With Spring Boot and Dapr

Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.

Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.

>> Flexible Pub/Sub Messaging With Spring Boot and Dapr

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:

Go to the Home Page
Open an Article from Home Page
Go to Guides/REST
Go to the REST Category
Go to the Full Archive
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.