Easy to set up, easy to extend: Gatling.
— 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!
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!
There are different ways to set up a Gatling project using a build tool, e.g. Maven, SBT or Gradle.
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 \
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.
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.
- 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
- in the root create `build.sbt` file and insert
val gatlingVersion = “3.5.0”lazy val root = (project in file(“.”))
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”,
- create `src` folder in root -> it is actually a place for simulations
brew install sbt
On this step, you’re done with setup. The structure of your project should look like this:
To execute simulations locally, run:
For a specific simulation:
sbt ‘gatling-it:testOnly test.Authentication’
For all simulations:
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!
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:
- sbt ‘gatling-it:testOnly tests.Authentication’
expire_in: 2 week
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.
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.
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.