Testing the limits of your application with Gatling

Why Gatling?

Probably we could test almost the same things with JMeter or even writing a whole new application just to send N requests. So why Gatling?

It’s all about DSL

Apache Camel is widely used in Java and one of its principal changes was to stop using XML and start using the Camel DSL.

We came from here:

1
2
3
4
<from uri="direct:start" />
	<idempotentConsumer messageIdRepositoryRef="repo" skipDuplicate="true">
	<header>MessageId</header> <to uri="log:org.apache.camel.spring.processor.idempotent?level=INFO&amp;showAll=true&amp;multiline=true" />
	<to uri="mock:result"/>

To here:

1
2
3
from('direct:test')
	.transform { it.in.body.reverse() + someValue}
	.setHeader("myHeader") { someValue.reverse() }`

And that’s where gatling shines!

Gatling DSL

Ignoring some configurations, the result from a recorded test will look like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
val scn = scenario("RecordedSimulation")
            .exec(http("request_0")
                .get(uri4 + "")
                .headers(headers_0))
            .pause(3)
            .exec(http("request_1")
                .get("/noticias")
                .headers(headers_1))
            .pause(6)
            .exec(http("request_2")
                .get(uri4 + "")
                .headers(headers_0))
            .pause(5)
            .exec(http("request_3")
                .post("/noticias")
                .headers(headers_3)
                .formParam("q", "alex"))
setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)

And this all was generated by Gatling recorder. For my need, I want to test what will happen in the above scenario, if 100 users access at the same time.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
val numberOfUsers = 100
val scn = scenario("RecordedSimulation")
            .exec(http("request_0")
                .get(uri4 + "")
                .headers(headers_0))
            .pause(3)
            .exec(http("request_1")
                .get("/noticias")
                .headers(headers_1))
            .pause(6)
            .exec(http("request_2")
                .get(uri4 + "")
                .headers(headers_0))
            .pause(5)
            .exec(http("request_3")
                .post("/noticias")
                .headers(headers_3)
                .formParam("q", "alex"))
setUp(scn.inject(atOnceUsers(numberOfUsers))).protocols(httpProtocol)

Some resources to play in the wild https://gatling.io/docs/current/cheat-sheet/

Ok, how we do?

First, Gatling is really well documented here https://gatling.io/docs/current/quickstart/ then, knowing this content, the steps are

• Recording your first test
• Running your first test
• Improving your first test

To record, we will use Recorder located in $GATLING_HOME/bin/recorder.sh that have a friendly UI to help. Again, Gatling is really well documented on how to record your tests.

From Linux, because I’ve didn’t want to change any environment configuration to set a proxy, I’ve used a google-chrome plugin called SwitchyOmega.

Now, our record should be in $GATLING_HOME/user-files/simulations/RecordedSimulation.scala with a content like our previously DSL. To run the recorded scenario, use $GATLING_HOME/bin/gatling.sh, that one without UI.

1
2
Choose a simulation number:
   [0] RecordedSimulation

Type 0 (zero) and follow the instructions. Once you finish it. Time to see the reports in $GATLING_HOME/results/0-1524494019638/index.html.

Now how to improve our tests? Our tests are generated in plain Scala, add or remove methods in order to reflect the scenario you need, like, number of users, loops, conditions and other helpers that you can see in https://gatling.io/docs/current/cheat-sheet/.

Conclusions

Besides this article still is a WIP. Gatling has a lot of cool features, and I question if we should ship some schedule tests to test our application resilience inside our pipeline.