Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Running Gatling With a Distributed Environment

DZone's Guide to

Running Gatling With a Distributed Environment

Here's a solution for the setup of distributed machines running Gatling load tests to have them return a consolidated report.

· Performance Zone
Free Resource

This article is a continuation of this article on Gatling.

We wanted to produce a huge load on the system so, if I run it from a local machine, the Gatling requests would share the resources of the machine (CPU, memory, and network) and many of the cases JVM failed with the OutOfMemory issue.

The solution: we need to setup distributed machines which will run the Gatling load test and will provide me a consolidated report.

The options I can think of are AWS cloud EC2 instances, or OpenStack servers (private cloud), and I choose OpenStack. Now, if you don’t want to hold the servers, then you can use the Docker image to provision the machine, which will have a Gatling environment.

It's a simple configuration, so you have 4-5 machines, either provisioned from AWS or from OpenStack. These machines are capable of running Gatling. To make this setup easy and shareable, one can create the image of the basic setup or create a HEAT template (if using OpenStack).

Consider that you have n number of machines with the capability to run the Gatling. Now the question is how you can distribute the load and get a consolidated report.

Consider the below points for your setup:

  • Distribute your test data in chunks. I have used a CSV feeder which needs data to be added in the CSV file. Simple command line scripts split my test data CSV files into 5 files, then copy those files to the destination servers. This is one approach if you don’t want to use the same data on distributed machines. Another approach is that you can configure the Redis as a feeder and then distribute the data on separate databases.

  • If scripts and related files are updated, then you need to copy them to the destination folder. I have used a Git to manage this. My custom Gatling executor first checks out the files from the Git to the local folder to ensure each machine has the latest code.

  • Using the -df <path> command line option, you can specify the folder from where you want to load the data files. The default is GATLING_HOME/user-files/data. To simplify, I have added the 4 folders in data, with the names 10, 11, 12, and 13 (where the number is the last digit of the private IP of my machines), and using the –df command, I have selected the specific data folder to use, for example, Gatling running on the 10.0.0.10 machine will load data from folder /user-files/data/10.

  • To distribute the reports, you simply need to run Gatling with the –nr (no report) command. With this option, Gatling will create only the log file (which is used to generate the report). Once Gatling is done with the execution, check in those reports to the Git in a folder which is named with the timestamp.

  • I have created a simple bash script which uses ssh to trigger Gatling on the remote machine. This ensures the simultaneous execution on the 4 machines. Once the execution is complete, the script checks for the log files and runs a command (explained in the next point) to generate the consolidated report.

  • So now you have all the Gatling logs generated from the 4 machines in GIT. Now, either from the local machine or from Jenkins, you can generate the consolidated report. All you need to do is download all those logs and keep them in a folder, and then run the gatling.bat or gatling.sh file with –ro (report only) options. It will generate a consolidated report for you, and voila! You are done.

It seems like a very simple configuration. It’s up to you how you organize your data and distribute it so that you can run Gatling on multiple machines in simultaneous mode. Feel free to message me if you want more details on the scripts.

Topics:
test automation ,java ,gatling ,load testing ,performance ,web load testing ,load test ,performance testing

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}