Stressed

Running Tests

Gatling is a command-line program, which makes it easy to script tests. The gatlingdemo.sh script [2] can be run directly without parameters, in which case it will use all of the default directories and provide a list of all available Gatling tests in the simulations directory.

A convenient way of organizing tests is to have the source code and test results in separate directories, which can be accomplished by having all of the Gatling directories in a separate directory by test (Table 1). The example in Listing 5 is a simple script that runs a test and uses those local directories.

#!/bin/bash
CLASS=$1
SRC=`pwd`/simulations
RESOURCE=`pwd`/resources
RESULT=`pwd`/results
TMP=`pwd`/temp
DESC="desc goes here"
gatling.sh -sf $SRC -rsf $RESOURCE -rf $RESULT -bf $TMP -s $CLASS -rd DESC

All of the output goes to stdout. A small status block (Listing 6) lets you keep an eye on the status of the script that is running Gatling, with the successes and failures for each step output every five seconds. Normally you would not watch this output, but it is a convenient way to verify that everything is working as the script gets started. Once Gatling is finished running, it will output a final block with some statistics, as well as the directory where the output report has been generated.

================================================================================
2021-06-20 22:49:24                                          17s elapsed
---- Requests ------------------------------------------------------------------
> Global                                                   (OK=24     KO=0     )
> step_1_getpage                                           (OK=3      KO=0     )
> step_1_getpage Redirect 1                                (OK=3      KO=0     )
> step_2_reserve                                           (OK=3      KO=0     )
> step_2_reserve Redirect 1                                (OK=3      KO=0     )
> step_3_purchase                                          (OK=3      KO=0     )
> step_3_purchase Redirect 1                               (OK=3      KO=0     )
> step_4_confirm                                           (OK=3      KO=0     )
> step_4_confirm Redirect 1                                (OK=3      KO=0     )
---- BookFlight ----------------------------------------------------------------
          active: 0      / done: 3
===============================================================================

Gatling Output

Reports are generated as HTML (Figures 3 and 4), and all reports can be made available over your intranet, where users can view them with their web browser. Because the reports are powered with a bit of JavaScript, you can zoom in and inspect the steps and define the starting and ending times.

Figure 3: Results in tabular form.

Figure 4: Graphs of response times.

Full Test

A BlazeMeter [3] sample website simulates a travel site that can be used for testing JMeter. HTTP calls made to this site step through the simulated process of booking a ticket. Because Gatling can also make HTTP calls, you can also use this same website to test your skills. Booking a ticket on the site takes four simple steps:

• Choose departure and destination cities
• Pick an airline
• Enter payment details
• View the confirmation

The calls for this test have been stored in their own Scala FlightSteps object for better clarity. The Scala code for this object is quite similar to those seen in Listings 1 and 3. All of the code for this test is available online [2], but perhaps the most interesting part of the test is the main script (Listing 7).

01 package com.mypackagename
02
03 import Scala.concurrent.duration._
04 import io.gatling.core.Predef._
05 import io.gatling.http.Predef._
06
07 import com.mypackagename.mySupport._
08 import com.mypackagename.FlightSteps
09
10 class BlazeBookFlight extends Simulation {
11
12  var qualifiedhost = "http://blazedemo.com"
13  var proxyhost = fetchEnvString("proxyhost","not set")
14  var proxyport = fetchEnvInt("proxyport",0)
15  var debug = 0
16
17  // http connector
18  var httpProtocol = http
19    .baseUrl(qualifiedhost)
20
21  if (proxyport > 0)
22  {
23    httpProtocol = httpProtocol.proxy(Proxy(proxyhost,proxyport))
24    println(s"proxyhost $proxyhost");
25    println(s"proxyport $proxyport");
26  }
27
28  val scn = scenario("BookFlight")
29    .exec(
30        FlightSteps.getSitePage,
31        FlightSteps.reserveFlight,
32        FlightSteps.purchaseFlight,
33        FlightSteps.confirmFlight
34      )
35    .pause(5)
36
37  setUp(
38      scn.inject(
39        constantConcurrentUsers(1).during(6.seconds),
40        rampConcurrentUsers(1).to(2).during(4.seconds)
41      ).protocols(httpProtocol)
42  )
43 }

Most of the first 26 lines of the test script are similar to the first Gatling example. It includes all the required Gatling include files (i.e. import io.gatling.core.Predef._), as well as two custom objects. Lines 13-14 retrieve values from Bash environment variables. When these variables are defined, the values will be used to set up the proxy. Lines 28-35 define the test scenario that performs the four steps of purchasing a ticket. The most important lines are 37-42. In this example, no real load is generated against the server, but it would be just as easy to change the code to run the scenario 50 or 100 times in parallel.

Although Gatling is a nice tool, you should compare it against alternative performance testing tools, such as the proprietary LoadRunner or the open source JMeter [4]. This exact same test with the BlazeMeter test site is also available in a previous article [5] for a direct comparison with JMeter.