Gatling’s Frontline on AWS: a load testing tutorial

Posted on 18 May 2020, updated on 21 December 2023.

A few weeks ago, my team and I had to deploy an infrastructure in five days on AWS: CloudFront, WAF, S3, API-Gateway, NLB, EKS, RDS. This infrastructure had to sustain 50 thousand calls in one minute on the backend (http PUT with INSERT INTO a DB) and 3 million users in 5 minutes on the frontend (http GET on a static page). To make sure everything would go smoothly when we go live, I deployed a Gatling frontline instance. Within a few minutes, we could start shooting. Within hours we had properly tuned and scaled our infrastructure. Here is how you can quickly start shooting as well.

Deploy a Frontline instance

A quick and easy way to deploy a frontline instance is by following the well detailed Gatling documentation. You will:

purchase the Gatling FrontLine ami from the AWS marketplace.
spawn an EC2 instance
connect to the Gatling interface with public IP of your EC2 and user/password

I started with the “frontline - Continuous Load Testing” free trial plan. It only provides a local injector. It was enough for my 50k load test. However, my injector ran out of CPU and connections for the 3M load test. I could quickly upgrade to the “frontline - Distributed Load Testing” plan which allows you to simultaneously run 3 tests with pools of 3 injectors.

Write a Gatling HelloWorld script

Gatling provides a scala framework. It is very intuitive, rusty java memories (like mine) will get you far enough. For instance, a simple http GET looks like this.

As I use maven as package manager here is the configuration file provided by Gatling.

The `pom.xml` should be placed at the root of your project whereas the scala code should be placed at `./src/test/scala/helloword/HelloWorldSimulation.scala`. Push everything on a git repository and follow me to the next part to run the simulation.

I can not show you bits of code we used. All I can say is the Gatling framework is very intuitive. We could easily do dynamic or randomized tests, as well as ingest data from sources.

Give frontline access to your code

You can load your code in different ways. As we are aiming for speed, lets us directly build the code from a git repository. Go to `Admin > Repositories > Create` and enter the following information.

I like to write a small ci/cd file and push the .jar on an s3 bucket. You can also provide a binary repository!

Upgrade injector pools

You can quickly run out of CPU or TCP connections for instance if you only use a small local injector. You need to parametrize a pool of injectors go to `Pools > Amazon EC2 > Create` and fill up the information related to your infrastructure. Note that you will have to: give your Frontline instance the right to spawn EC2s, provide Frontline with an ssh private key and design your security groups so that Frontline can access its injectors both in ssh and http. In this article, we will go as fast as possible and directly run simulations from the local frontline injector.

Create a simulation

Back to the main page click to `Create` a simulation and provide the following information.

Run the simulation

Click on the play button and enjoy the show. I know it seems almost too easy

Now, this is when the fun part starts. Frontline provides you with a cool dashboard to help you understand what’s happening while you are load testing.

For instance, Frontline will provide you with a “Response time in percentiles” graph. Why percentiles and not mean and variance? Because As you can see on the “Response time distribution” graph, the response time is not generally normally distributed. They are several modes and each mode represents a bottleneck in your infrastructure. So if you have hands on all elements of your infrastructure (no external services), you could try tuning everything until there remains one mode to rule them all. How cool is that?

If you have implemented complex scenarios you can see details of each request. In the connections dashboard, you will see the number of connections you have established. In the injectors dashboard, you will get info on the health of your injectors. Take good care of your injectors because if not properly sized they will mess up your load tests.

All these metrics are pretty neat and it is fun to try and break in infrastructure, but none of this is useful unless you can have metrics on your infrastructure. In other words, for your load tests to be efficient, monitor everything you can on your infrastructure.

I hope this article helped you quickly set up a Gatling Frontline load test on AWS. I have now used Gatling’s Frontline on several projects and it has helped me quickly shoot, analyse, report, and tune my infrastructures. Fill free to share with me your experience with Frontline in the comments. Tips and tricks are much appreciated!