I had an opportunity to use Gatling for load testing in one of my recent projects. My learning curve for this tool was very steep and I found it very elegant, highly capable and easy to use. So thought I’ll share my learnings with everyone.

Gatling is an open-source load testing framework based on Scala, Akka and Netty. It comes with excellent support for HTTP protocol thus making it an easy choice to test HTTP server (web based applications, APIs etc). I am not providing too much detail here as its documentation is quite comprehensive and well organized. More details here.

Here, I’ll provide a step by step tutorial on how to create a Gatling simulation manually from scratch. It’s easier to create the simulation manually if you want to test web services. Gatling does provide a Recorder, a tool that allows you to record user actions on a web application and export them as a Gatling scenario just like its counterparts in Loadrunner and Jmeter. More details on the Recorder can be found here. We’ll also go through different ways to design scenarios with various load patterns, injection profiles etc.

Before going through this tutorial, I’d recommend you to try the Quickstart tutorial first to get familiar with basics of Gatling.

A Gatling simulation is a real Scala class in which you define almost everything required to run a load test i.e. input data, scenario configuration, requests, load injection pattern etc. The Scala class contains following parts

//define an optional package to hold the Scala class
package com.myproject.performance

//required imports
import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._

//class declaration
class BasicSimulation extends Simulation {
//Step1: Define Common HTTP protocol configuration
//Step2: Define Headers
//Step3: Define Feeders
//Step4: Define HTTP Requests
//Step5: Define Scenario
//Step6: Load Injection pattern
//Step7 (optional): Define before hook
//Step8 (optional): Define after hook
}

Let’s go through each step in detail.

Step 1: Define common HTTP protocol configuration

using which all the HTTP requests will be sent. It is defined as a Scala variable so that it can be passed later in the simulation definition. Following definition shows various parameters which can be used while defining the protocol configuration with baseURL being the core parameter.

val browserAppHttpProtocolConfig = http
.baseURL(testURLPrimary) //1 //OR
.baseURL(testURLPrimary, testURLSecondary) //2
.inferHtmlResources() //3
.acceptHeader("text/xml") //4
.acceptEncodingHeader("gzip, deflate, sdch") //4
.acceptLanguageHeader("en-US,en;q=0.8") //4
.userAgentHeader("Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36") //4
.disableWarmUp //5 //OR
.warmUp(testURLPrimary + "/your/own/healthcheck/url/ping") //6
.maxConnectionsPerHostLikeChrome //7
.silentResources //8 //OR
.silentURI(testURLPrimary + "/resources/.*") //9
.disableFollowRedirect //10 //OR
.maxRedirects(1) //11
.disableCaching //12

1. This baseURL will be prepended to all URLs that do not start with HTTP
2. Same as 1 but load testing several servers with client based load balancing. The selection of the URL is random.
3. Using inGatling will automatically parse HTML to find embedded resources and load them asynchronously. To emulate the behavior of real web browser
4. Various headers
5. Gatling automatically performs a request to http://gatling.io before starting the actual simulation. This is used to nullify the overhead introduced by java/NIO engine on the first request. Use this to disable the feature
6. OR use your own warm-up URL instead of default one
7. Gatling can run multiple concurrent connections per virtual user when fetching resources on the same host. The default value is 6. Use this parameter to use the built-in value for chrome browser. There are many other built-in values for different browser types, see here
8. Request stats are logged and then used to produce reports. Sometimes, some requests may be important for you for generating load, but you don’t actually want to report them. So we silence them by using this. Silent requests won’t be reported and won’t influence error triggers such as tryMax and exitHereIfFailed. Yet, response times will be accounted for in group times.
9. OR use this. Same as silentResources but silences only matching requests as per regular expression
10. To disable automatic redirects (happens by default) in case of HTTP 301/ 302/303/307 response status code for the original request
11. used to set the maximum number of redirects. To avoid infinite redirection loops
12. Used to disable caching. When a response gets cached, checks are disabled

 

Step 2: Define Headers

Gatling allows you to use common headers at HTTP protocol level (as mentioned in step 1 comment 4 above). You can also make use of the build in headers to pass to individual requests. Here are some of the header definitions. We will see in subsequent steps on how they can be used in the requests.

val jsonHeader = Map("Content-Type" -> "application/json; charset=UTF-8")
val ui_headers_0 = Map("Accept" -> "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8","Upgrade-Insecure-Requests" -> "1")
val ui_headers_1 = Map("Accept" -> "text/css,*/*;q=0.1")
val ui_headers_2 = Map("Accept" -> "*/*")
val ui_headers_3 = Map("Accept" -> "image/webp,image/*,*/*;q=0.8")
val ui_headers_4 = Map("Accept-Encoding" -> "gzip, deflate")

Next, we will define Feeders and HTTP requests. See here