Easy to set up, easy to extend: Gatling.

Getting started with API performance testing

ALTEOS Tech
Alteos Tech Blog

--

by Olena Semiankiv

What do you need to quick start?

The right tool with a variety of ready-to-use features and possibility to extend it!

Recently, at Alteos we started our performance testing project and I was looking for an appropriate tool for it. After some research, our choice fell on Gatling.

Gatling is an open source, Scala-based tool for load testing, which will help you measure the load your API can handle.

It has many advantages — the main one for us being:

- Easy DSL (Domain Specific Language), which makes scripting much easier

- Full power of Scala (and therefore of Java) “under the hood”

- Automatically generated HTML report

- Real time metrics via Graphite protocol with InfluxDB and Grafana, that helps you keep execution under control

- Your tests can be easily integrated to a CI/CD pipeline — which otherwise, with JMeter, is rather troublesome

…and of course brilliant documentation!

From https://gatling.io/

There are different ways to set up a Gatling project using a build tool, e.g. Maven, SBT or Gradle.

First, we adopted an “easy” approach: a ready-to-use solution: pull a denvazh image from Docker Hub and write first simulations (test scenarios in terms of Gatling).

With this approach, you just need to run a Docker container with mounted configuration and simulation “test” files.

docker run -it — rm -v /home/core/gatling/conf:/opt/gatling/conf \
-v /home/core/gatling/user-files:/opt/gatling/user-files \
-v /home/core/gatling/results:/opt/gatling/results \
denvazh/gatling

It was an easy and functional solution for some time, but…

we needed to write data to DB on test setup. We were thinking about gatling-jdbc, but it wasn’t really simple to do with the adopted solution.

In addition, developing tests wasn’t easy either, due to the absence of code compilation and difficulties when debugging the code.

So it was time to set up the project in a proper, scalable way.

From https://www.britannica.com/

After reading the Gatling documentation, we found out that it’s possible to use Gatling as SBT plugin. SBT is an open-source build tool for Scala and Java projects, whose functionality can be extended through a plugin architecture.

This made our life much easier, because now we are free to use any libraries and extend the framework according to our needs.

SBT gives you the opportunity to run tests locally with code compilation, so error handling is much faster.

In addition, with a proper IDE, Scala plugin code completion is there for you.

Steps:

  • create directory `performance`
  • make repo `project` -> create `plugins.sbt` file and insert
addSbtPlugin(“io.gatling” % “gatling-sbt” % “3.2.1”)
  • in the same folder create file `build.properties` and insert
sbt.version=1.5.0
  • in the root create `build.sbt` file and insert
val gatlingVersion = “3.5.0”lazy val root = (project in file(“.”))
.enablePlugins(GatlingPlugin)
.settings(
scalaVersion := “2.13.4”,
libraryDependencies ++= Seq(
“io.gatling.highcharts” % “gatling-charts-highcharts” % gatlingVersion % “it”,
“io.gatling” % “gatling-test-framework” % gatlingVersion % “it”
),
scalacOptions := Seq(
“-encoding”, “UTF-8”, “-target:jvm-1.8”, “-deprecation”,
“-feature”, “-unchecked”, “-language:implicitConversions”,
“-language:postfixOps”
)
)
  • create `src` folder in root -> it is actually a place for simulations
  • run:
brew install sbt

On this step, you’re done with setup. The structure of your project should look like this:

performance
- project
- build.properties
- plugins.sbt
- src
- build.sbt

To execute simulations locally, run:

For a specific simulation:

sbt ‘gatling-it:testOnly test.Authentication’

For all simulations:

sbt gatling-it:test

With the current setup we were able to use gatling-jdbc just by adding one line into `build.sbt`:

“org.postgresql” % “postgresql” % “42.2.5” % “it”

Now we have our simulation ready for performance testing!

From https://www.theporteport.com/

We set up pipelines in GitLab and run them on demand for now, via a ready-to-use SBT docker image.

Here’s a short example of how the simulated execution step could look like in the pipeline configuration file — in our case, the .gitlab-ci.yml file:

Run Authentication Simulation:
stage: test
tags:
- kubernetes
when: manual
variables:
URL: “http://localhost/"
script:
- sbt ‘gatling-it:testOnly tests.Authentication’
image: hseeberger/scala-sbt:graalvm-ce-20.3.0-java8_1.4.4_2.13.4
artifacts:
expire_in: 2 week
paths:
- /performance/target/gatling-it
when: always

There are still a few steps to take next: storing logs, setting up the Grafana dashboard — to better analyze test results and keep them under control; as well as integrating tests to the CI/CD pipeline.

But even at this stage, tests are already useful and helped us to identify a few weak spots in the system.

In conclusion…

I would like to emphasize that one should use the right tool for one’s needs. It was a great experience with the easy start of Gatling plus pre-built Docker image.

One can play around with the tool without a long setup; and spot results right away. When the project “matures” and new problems arise, the tool provides the flexibility and power of a huge community.

Switching from a Gatling Docker image to an SBT plugin was straightforward. Using developer tools like SBT might sound complicated…

But be brave, the community is there to help you! And with this help, new discoveries won’t keep you waiting.

About me:

Working at Alteos as a QA Lead. Born in sunny Ukraine, living in rainy Berlin. Keeping an eye on product quality — building automation means to reduce manual work.

Follow ALTEOS Tech and our publication, stay tuned for more stories by our tech team!

--

--

ALTEOS Tech
Alteos Tech Blog

Alteos unleashes the potential of a digital insurance