Table of contents

Reading Time: 4 minutes

Every time we write code, we think if it works fine on local, it would work fine on production too. We do check on production as well but for limited users or non-real scenarios. A system may run very well with only 1,000 concurrent users, but how would it run with 100,000? It may or may not respond on time.

Are we doing anything to deal with this kind of situation?

Flipkart’s Biggest Sale or Biggest failure?

Everyone has heard of the “Big Billion Sale” by Flipkart on 6th October 2014. Products were priced as low as Re.1, and in some cases, discounted as high as 80%.
BigBillionDay suffered from technical glitches despite Flipkart deploying an additional 1000 engineers.

“With a large number of people reaching out, Flipkart should have had a data center to handle peak traffic. This is just another instance of not having a strong back-end to hold on to enormous transactions,” said Sanchit Vir Gogia, Chief Analyst at Greyhound Research, a technology research firm.

Solution? – Performance Testing

Performance Testing is a type of testing to ensure software applications will perform well under their expected workload.
It evaluates the quality or capability of a product.

There are lot many performance testing tools available in the market.
Apache JMeter, IBM Performance tester, NeoLoad, LoadRunner, smartmeter.io, Test Studio, WebLoad and CloudTest to name a few.

In this blog, we are going to learn about a new Performance testing tool: Gatling.

Gatling

Gatling is an open-source load testing framework based on Scala, Akka, and Netty.
It provides us:

High performance
Out-of-box HTTP support
Ready-to-present HTML reports
Scenario recorder and developer friendly DSL

Gatling is Powerful. Like how?

It uses advanced architecture and the Akka toolkit, which is based on the actor model that is distributed and fully asynchronous by design.
Gatling doesn’t allocate a separate thread for each user.
Instead, all multithreading is done via messages between actors which allow simulating a list of users by using just one thread.

Ok…talk is easy, show me the code!

In project/plugins.sbt, add:

addSbtPlugin("io.gatling" % "gatling-sbt" % "2.2.2")

You’ll also need to add these two dependencies:

"io.gatling.highcharts" % "gatling-charts-highcharts" % "2.3.0" % "test"
"io.gatling"            % "gatling-test-framework"    % "2.3.0" % "test"

A basic Gatling simulation script looks like this:

class SingleScenarioSimulation extends Simulation {

  val httpConf: HttpProtocolBuilder = http
    .baseURL(PROJECT_BASE_URL)
    .acceptHeader("image/png,image/*;q=0.8,*/*;q=0.5")
    .acceptEncodingHeader("gzip, deflate")
    .acceptLanguageHeader("en-US,en;q=0.5")

  val registerRequest = """{"userName":"${username}","emailID":"${email}","password":"${password}"}""".stripM<span id="mce_SELREST_start" style="overflow:hidden;line-height:0;"></span>argin

  val requestFeeder = csv("data.csv").circular

  val scn: ScenarioBuilder = scenario("Register User")
      .feed(requestFeeder)
      .exec(http("Registration Request")
        .post("/user/registation")
        .body(StringBody(registerRequest)).asJSON
        .check(jsonPath("$.status").is("200"))
    )

  setUp(scn.inject(atOnceUsers(5)).protocols(httpConf)).assertions(
    global.responseTime.max.lt(50),
    global.successfulRequests.percent.gt(95)
  )
}

So, basically, it consists three main parts:
1. Scenario: A scenario consists of a series of requests. Each scenario within a simulation can have its own injection profile.

2. Request: Gatling is able to simulate complex users’ behaviors. For this purpose, it generates the appropriate requests in the system under test.

3. Injection profile: An injection profile is the number of virtual users injected during the test in the system under test and how they are injected.

Simply, we are going to define our HTTP request by defining its basic URL and the headers information, if any. Then, the scenario will execute the actions we specify. Like, in this case, we are defining the Register route and passing the request parameters as JSON body. This scenario will check if the response is OK(200).

There are several types of Feeders available to inject data into your scenario. For example, csv, tsv, ssv, jsonFile, jsonUrl, jdbsFeeder, and redisFeeder.
The most simple being the CSV Feeder: this is the one we are using in our test. Then, it is fed to the request made. You can create this file in the resources folder.

  val requestFeeder = csv("data.csv").circular

Here, we also mention the feeder strategy, i.e. circular in this case. This strategy takes the values of the feeder in their order, and when it reaches the last, it returns to the first one.
Other feeder strategies could be random, queue and shuffle.

Lastly, we set up the scenarios that will be launched in the Simulation.

setUp(scn.inject(atOnceUsers(5)).protocols(httpConf))

Here, Inject Profile controls how users are injected in your scenario.
atOnceUsers injects a specific number of users at the same time.
Here, we are saying inject 5 users at a time.
Other Inject profiles could be nothingFor, rampUsers, constantUsersPerSec, rampUsersPerSec, splitUsers, and heavisideUsers.

Finally comes the assertions which check if your results match your expectations or not.

assertions(
    global.responseTime.max.lt(50),
    global.successfulRequests.percent.gt(95)
  )

There’s a whole list of assertions we can put.
Here, we are checking if we are able to get response time to be maximum 5 milliseconds and successful request percentage to be 95% minimum.

So, after running this, we get:

Here, you can see the results with all the details. OK stands for the number of successful requests and KO is the number of failed requests.

Another real power of Gatling is detailed metrics dashboard out of the box. Below these results, link to the Gatling reports is given. Here, you can see the generated reports which include.