This blog is basically for the one who wants to do performance testing using the Gatling tool. Before starting with the actual Gatling tool we will have a brief introduction of performance testing.
What is Performance Testing?
Performance Testing is defined as a type of software testing to ensure software applications will perform well under their expected workload. Here expected workload is that which makes the difference between Performance testing and Load testing.
Performance Testing is a type of software testing that is carried out to determine system performance under varying load. Load testing is a kind of Performance Testing which determines a system’s performance under real-life load conditions. This testing helps determine how the application behaves when multiple users access it simultaneously.
You might think why I am talking about Load testing here. The reason is just that Gatling is designed to be used as a load testing tool for analyzing and measuring the performance of a variety of services.
The reason of these testings is checking a software program’s:
- Speed – Determines whether the application responds quickly
- Scalability – Determines the maximum user load the software application can handle.
- Stability – Determines if the application is stable under varying loads
Why do Performance Testing?
Performance Testing uncovers what needs to be improved before the product goes to market. Without Performance Testing, the software is likely to suffer from issues such as: running slow while several users use it simultaneously, inconsistencies across different operating systems and poor usability.
Why Gatling?
Different tools of Performance Testing… If you search for performance testing tools, you will find a number of tools available(for eg. JMeter, LoadRunner, etc). These tools have advantages over each other related to user load support, resource utilization, reporting, etc. Engineers in top software testing companies with knowledge of Scala would prefer Gatling as it provides nice reporting and also utilizes fewer resources such as memory, CPU during the load test as compared to other tools.
Gatling:
Gatling is an open-source load and performance testing framework based on Scala, Akka, and Netty. The first stable release was published on January 13, 2012. Gatling uses Netty Netty for non-blocking HTTP. Gatling deals with virtual users, each one having its own data. Some other tools implement those virtual users as threads. Gatling implements them as messages, which scales much better and can deal easily with thousands of concurrent users. Gatling is written in Scala, which allows us to run it on any system. That’s why you will never hit any trouble by using different local machines and cloud servers to run and create your tests.
So let’s start with how Gtaling works for testing and what kind of test cases and results get generated. Gatling provides an official sbt plugin named gatling-sbt. This plugin lets you launch your Gatling simulations. Check the sbt plugin documentation for more information.
Gatling Tool Structure:
The above image shows how the Gatling structure looks like. Here: bin: Contains launch scripts for Gatling and Recorder conf: Contains the configuration files for Gatling, Akka and Logback lib: Contains the binaries used by Gatling results: Contains report generated user-files: Contains simulation scala files
Gatling Recorder:
The Gatling Recorder helps to quickly generate scenarios, by either acting as an HTTP proxy between the browser and the HTTP server or converting HAR (Http ARchive) files. As bin contains launch scripts for Gatling and recorder. The Recorder script can be launch with ../bin/recorder.sh as shown in the following image.
This tool is launched with a script located in the bin directory recorder.sh on Linux/Unix and recorder.bat on the windows OS. Once launched, the following GUI lets you configure how requests and responses will be recorded.
Here, you can browse the HAR file from your device or can continue with HTTP Proxy(check recorder reference page) instead of the HAR file. After configuring the recorder, all you have to do is to start it. It will generate different scenarios in the simulation folder( shown in the above image). So let’s have a look at those scenarios.
Gatling Test Structure:
As you can see in the above image we have Simulation class in our test suit or any class which extends basic Simulation class. In the Simulation class, we have multiple scenarios which contain different HTTP request like get/post calls. Again in the same class, we have one HTTP protocol which contains base URL i.e it contains all common configurations(like prefix in routes file). All requests in that scenario uses the base URL. setUp() is the Gatling simulation base method. The setUp() call the scenario object and passes the number of users using different injection profiles.
Let’s have an example:
import scala.concurrent.duration._
import io.gatling.core.Predef._
import io.gatling.http.Predef._
class RecordedSimulation extends Simulation {
val httpProtocol = http
.baseUrl("http://localhost:9000")
.inferHtmlResources()
val scn = scenario("RecordedSimulation”)
.exec(http(“request_0”)
.get("/category/all"))
.pause(5)
.exec(http(“request_1”)
.get("/assets/images/gears.gif"))
setUp(scn.inject(atOnceUsers(10))).protocols(httpProtocol)
}As here, we have baseUrl “http://localhost:9000”, two get requests in the scenario and testing this scenario for atOnce 10 users. This is how the Gatling test structure looks like.
So far we should know how to record a simulation and what simulation consist of. Gatling has a pretty cool looking report. It shows global information about simulation and more detailed information for each request or request group. To generate the report we run the gatling.sh(./gatling.sh) file from the bin directory. it will generate the Html file showing the pretty cool looking report which looks like:
Gatling report is a valuable source of information to read the performance data by providing some details about requests and response timing.
This is how the Gatling tool can be used to test the performance of the application and uncovers what needs to be improved before the product goes to market.
References: https://gatling.io/docs/current/