Simulation structure

A Simulation is a real Scala class containing 4 different parts:

  • The HTTP protocol configuration
  • The headers definition
  • The scenario definition
  • The simulation definition

To illustrate this point we will take one of our sample simulations: computerdatabase.BasicSimulation

HTTP protocol configuration

The first element is the configuration of the HTTP protocol. In this example, this configuration is very basic and just defines:

  • the baseURL, which will be prepended to all the relative paths in the scenario definition. Here, the base URL is
  • common headers, which will be added on each request.

The HTTP Configuration is stored as a Scala value so that we can set it later in the simulation definition.

Headers definition

As you’ll see later, when we define the scenario for Gatling, we can provide the headers used for each request sent to the server. As the file was generated by the recorder, all headers are declared in the beginning of the file and used in the scenario definition.


Adding common headers can seem useless, but don’t forget that they add load on your server and have a real impact on the server behavior (like Accept-Encoding or If-Last-Modified).

Headers are declared as Scala Maps:

val headers_10 = Map("Content-Type" -> """application/x-www-form-urlencoded""")

Scenario definition

After the headers definition comes the scenario definition. This definition has a name because you can define several scenarios in the same simulation. A scenario is usually stored in a Scala value:

val scn = scenario("ScenarioName") // etc...

The scenario structure basically consists of chaining two methods: exec and pause. The first one is used to describe an action, usually a request sent to the tested application; the second one is used to simulate the think time of the user between consecutive requests.

HTTP requests are defined as follows in a scenario:

// Here's an example of a POST request
  .formParam("name", "Beautiful Computer")
  .formParam("introduced", "2012-05-30")
  .formParam("discontinued", "")
  .formParam("company", "37")

The above example produces a POST HTTP request that creates a new computer model:

HTTP request:
  Accept: [text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]
  Content-Type: [application/x-www-form-urlencoded]
  DNT: [1]
  Accept-Language: [en-US,en;q=0.5]
  Accept-Encoding: [gzip, deflate]
  User-Agent: [Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20100101 Firefox/16.0]
  Referer: []
  company: [37]
  discontinued: []
  name: [Beautiful Computer]
  introduced: [2012-05-30]

Simulation definitions

The last part of the file contains the simulation definition, this is where you define the load you want to inject to your server, e.g.:

  scn.inject(atOnceUsers(1)) // (1)
    .protocols(httpConf) // (2)

which correspond to:

  1. We inject one single user into the scn scenario
  2. We configure httpConf on the setUp so that we pass the base URL and the common headers.


Gatling provides two hooks:

  • before for executing some code before the simulation actually runs
  • after for executing some code after the simulation actually runs
before {
  println("Simulation is about to start!")

after {
  println("Simulation is finished!")


You won’t be able to use Gatling DSL in there, as it’s only intended for load test. You can only use your custom code.