Load Testing and Cloudification using Gatling

When we developed the FastContest application and deployed it on the Amazon cloud using Cloudify, we decided to perform automated load tests to:

• evaluate the maximum load that our application could support
• size the Cloud machines on which we deploy
• highlight the weaknesses of our application
• run automatically defined scenarios with hundreds of simultaneous players and check the integrity of the outcome data.

We chose to use Gatling, an open-source load test tool. Gatling lets you write test scenarios in the form of concise and elegant code.

Cloudify, open source, and native to any language + environment. Try it out.  Go

Gatling Tree Diagram

The Gatling installation folder is organized according to the following tree diagram:

• /results: contains the benchmark results in web format
• /bin: contains the scripts for launching Gatling
• /target: contains the files resulting from the compilation of our scenarios + cache
• /conf: contains configuration files (log level…)
• /user-files: contains the .scala scenario definition files
• /lib: gatling jar

Scenarios implemented in Scala

Unlike JMeter which has a graphical interface for defining simulation scenarios and their parameters, Gatling offers an API written in Scala. Surprisingly, counter-intuitively, it is quite elegant and easy to define scenarios in Scala rather than via a graphical interface, especially since you don’t have to be a Scala ninja to create your first scenarios. Gatling offers many features. The basic functions of them are described below.
Full documentation is available at this link.
The scenarios are placed in the /user-files/simulations folder. Here is a typical scenario implemented in Scala:
In this case, Gatling will perform a post/user/register request with email and password parameters (defined in a separate file), and will check that the response has a 200 status. This means, after a pause of 0 to 100 ms,  Gatling makes 10 requests/responses with a pause of 0-5 seconds between each request. A “feeder” provides the parameters for parsing variables in, for example, a CSV file (for more information, follow this link).
To learn how to write a scenario with Gatling, see the official tutorial.

Running the benchmark

To launch a scenario, just run the gatling.sh or .bat script, depending on the environment, which is found in the /bin folder. Gatling will automatically compile Scala classes and then will ask you to choose the scenario to run. At the end of the simulation, a web report is generated automatically from the log file. It contains all the metrics arranged graphically using the HighChart Javascript library.
Sample report:

Cloudification

To perform load tests in near real conditions we have cloudified Gatling by automating its installation and operation on Amazon VMs.
With Cloudify, we can now launch load tests on the Internet on as many machines as we want. The recipes are relatively simple, since essentially all you have to do is download and unzip the Gatling installation folder. Since the scenarios are uploaded with the recipe, they must be placed in the Gatling /simulation directory.
The bench is run using a custom command “executeBench”, with the name of the scenario to be run as the first parameter and the name given to the simulation as the second. The custom command then launches the load test for all instances of Gatling on each VM. Reports are generated individually on each VM.
To get a single report, you can write a script that retrieves all the results generated, merges them and generates a new global report.
The report is then pushed onto S3 either automatically or via a custom command (pushResult).
Through this use case you can see once again how simple and convenient Cloudify is to use by fully automating the chain — deployment, installation and execution of load tests — from the Amazon EC2 Cloud.

Conclusion

One of Gatling’s most important advantages is undoubtedly its ability to generate high quality graphic reports at the end of each simulation. This way the tester can immediately view the results, without additional post-processing.
Plus, writing test scenarios functionally in Scala can make the test easier to read, especially thanks to feeders which let you parse the parameters in separate files.
Finally, launching tests via simple scripting commands makes them

A big thanks for this community contributed post by FastConnect.  See the original post in French here.

About FastConnect

As a leader in distributed computing architectures, FastConnect brings its unique expertise to assist you in redesigning your information and your business applications involving system implementation methodologies and the most advanced technologies.
FastConnect accompanies you during the audit phase and consulting, technological choices when defining target architectures (THINK), in coordination throughout your project and in technical implementation (BUILD) as well as during phases of operation (RUN). Our added value is based on a real sense of service and strong technical expertise supported by strategic partnerships and publishers active in the areas of distributed and complex application architectures.

Follow @fastconnect and @gauvaing on Twitter.