If you are new to the Gatling performance tool then first install and configure Gatling from Here. Check this article to understand What is Gatling and how to use it to write Java-based performance tests. In this article, we will understand how to perform load simulation in Gatling.
What Is Simulation In Gatling
Simulation is the description of the load test written in the script. It can be written in Java, Scala, or Kotlin. Simulation scripts consist of scenarios, HTTP configurations and user loads, etc. Simulation is the parent class your tests must extend so Gatling can launch them.
Components Of Gatling Simulation Script
- Package (optional)
The package is optional. If you provide the package name on the recorder screen then it will generate the script under that package.
- Imports (Required)
- Class declaration (Extends Simulation)
- A common configuration for all requests
HTTP is the main protocol Gatling targets. Common configuration includes baseUrl, headers which will be preponed to every HTTP request.
- Scenario Definition
We can have one or more scenarios in the simulation script. The scenario represents the operations performed by the virtual users throughout the performance test.
- HTTP requests
- Request URL and other details
- Pause / Think Time
This mimics the actual user behaviour. We can update the Pause/think time as required.
- Scenario setup simulation(Mandatory)
{
setUp(scn.injectOpen(atOnceUsers(1))).protocols(httpProtocol);
}
Here setUp is the method in which we have provided the user load as a single user and defined the HTTP protocol. We can modify this setup method to add the different HTTP configurations or add the same HTTP configurations to different scenarios.
Understand Gatling Script
In the last article, we recorded and executed our first Gatling script. Let’s understand a few of the concepts in this script. Gatling works at the HTTP protocol level. First, create the HTTP object, and then we can use it.HTTP is a method provided from HttpDsl
and is our starting point.
private HttpProtocolBuilder httpProtocol = http
.baseUrl("https://api.demoblaze.com")
.inferHtmlResources(AllowList(), DenyList());
The Scenario represents the operations our virtual users perform throughout the performance test.
scenario("Scenario")
.exec(http("Home").get("https://gatling.io")).exec(http("Enterprise").get("https://gatling.io/enterprise"));
The exec() method is used to execute an action. Actions are usually requests (HTTP, LDAP, POP, IMAP, etc) that will be sent during the simulation. Any action that will be executed will be called exec(). We can chain different actions of our scenario using exec().
pause(10);
pause(Duration.ofMillis(100));
pause() method is used to include pause/wait in the script.
Configure Virtual Users
Till now we have used Gatling with a single user but that’s not the ideal scenario, right? As in the real world, we do performance testing to check the system’s performance with the expected load. So let’s configure some virtual users and try to ramp up the load.
- Define multiple scenarios (like browse, select, add To Cart, Delete).
- Define multiple sets of users and assign modules.
For example, consider 2 roles as Admin and RandomUser. Admin can perform all the scenarios and RandomUser is restricted to only browsing and addToCart.
private ScenarioBuilder RandomUser = scenario("demoblazeSimulation01").exec(selectItem,addToCart);
private ScenarioBuilder Admin = scenario("demoblazeSimulation02").exec(selectItem,addToCart,deleteItem);
Ramp Users Load Simulation In Gatling
Gatling’s DSL is very flexible, allowing us to implement many different scenarios. Our target is to check the system’s performance with these different roles, so we will be ramping up the load for 10 RandomUsers and 4 Admin users within 10 seconds.
{
setUp(admin.injectOpen(rampUsers(10).during(10)),
users.injectOpen(rampUsers(2).during(10))).protocols(httpProtocol);
}
Now execute the Engine class and check the simulation results.
Open the HTML report in the browser and navigate to the Active Users section. Here we can see different active users with different ramp-up times.