User story #2


Both the Digital Load Test Team and various product teams use Gatling as a core part of our load testing effort.

Why Gatling?

There are three major factors that attracted us to Gatling:

  1. The HTTP DSL
  2. The reporting
  3. Its concurrency model


There are a number of load-test tools that only allow tests to be written in the GUI or through XML files. We wanted test-scripts that were easily understandable and that could be committed to a version control system.


The interactive JavaScript reports that are produced after the test run are extremely impressive and product teams have been keen to receive the reports and analyse the results themselves.

The integration with Graphite/InfluxDB and Grafana was also key for us as we are now able to provide real-time graphing for product teams to view during the test run.

Concurrency Model

With a synchronous concurrency model it is necessary to use multiple machines just to achieve several hundred requests per second. Scaling-out can be tricky to manage and costly when running from The Cloud. We have managed to achieve a high concurrency rate with Gatling using only a modest GNU/Linux box.

The Story

Apart from myself there are two other load-testers in the Digital Load Test Team who cover an array of application products and services. Our two main tools include Gatling and a proprietary tool.

We feel that Gatling encourages collaboration with product teams throughout the load-testing process. Firstly, performance requirements are written on a wiki, translated into a Gatling test script and then pushed to our Github repository. Here the test is reviewed by a member of the product team. This is important because the developers do not need to install a load-test tool or wade through masses of XML in order to review the test. The DSL can be read by all and invariably changes are requested by stakeholders when a concrete test is seen.

We have created Grafana and InfluxDB Docker images that can be run to receive out-of-the-box real-time graphing and metric storage. This allows both ourselves and our product teams to view the progress of the test run and use SQL like queries to retrieve data related to specific time series data.

The automatic generated reports are tarballed and uploaded to a server for stakeholders to access.

The Future

The general tendency towards Cloud deployments has led to a new dynamic with regards to load-testing. There has been a tendency to rely less on a centralised load-test team running on an internal infrastructure towards a model where developers and testers are spinning up instances and running load-tests themselves. Gatling is a perfect fit for this and we are starting to help product teams run Gatling as part of their Continuous Delivery pipeline utilising the Gatling Jenkins plugin.