Using Gatling to track your site’s performance

In a previous post, we showed how we could track the duration of our existing automated functional tests, allowing us to detect any anomalies between different builds. Timings API gave us the opportunity to use the same tests for both functional verification as well as performance. However, this may not be the best way to be sure that under specific (regular or higher than normal) traffic conditions, the site or application still performs as expected. To ensure that the system behaves normally under load, we need to generate simulated traffic and measure performance-related metrics. One of the solutions that are growing in popularity is Gatling.

Gatling offers both an enterprise solution called Gatling Frontline as well as a free open-source tool. In this post, we will mention only the free open-source version of Gatling. One of the highest selling points of this tool is the way its build on top Akka allowing the simulation of thousands of virtual users from a single machine. On the contrary, JMeter would need more resources to create the same amount of simulations. Not to forget that it has its own expressive DSL allowing code-based scenarios to be maintainable and stored within version control systems.

Types of Performance Tests

When we talk about Performance Testing, there are different reasons and situations why we would want to run these checks. For example, we would want to know the upper limits of capacity that the system can handle before it degrades. We can also run a specified load for a number of hours to make sure that performance keeps at an acceptable level for a long time. Another scenario would be that of ensuring that a new system build persists the same quality of performance as the current live build.

With Gatling, we can simulate a user scenario for a frontend website by using the provided Recorder tool. This tool allows you to set up a proxy and connect your browser to it, enabling you to then go once through the scenario as a typical user would and be able to automatically generate a script. This script will be then used to repeat the scenario for the desired amount of virtual users.

Getting started using Maven

To quickly create scenarios, you can start a new Maven project by using the Maven Archetype: -highcharts-maven-archetype. To do this, follow the screenshots below. The example is shown using IntelliJ IDE.

Once ready, Enable Auto-Import so that Maven downloads all the required dependencies. You should be able to see a similar project structure as shown below.

Let’s create a Scenario

Now the simplest way to start creating your scenarios is to use the Gatling Recorder. Right click on the Recorder file under the ‘ scala’ folder, and choose ‘Run Recorder’. This will launch the Recorder window.

There are two ways you can make use of the Recorder to generate your simulation, the first one is to set up the proxy and connect your browser or OS to it, or else you can save a HAR file from your browser. In this post we will go with the latter.

The scenario that we will generate is very simple. We will open the site http://testautonation.com, and then go to the TestAutonation Team page. To create our HAR file, let’s open a new Chrome window and open the Chrome Dev Tools by right-clicking on the page and choosing ‘Inspect Element’. Now we can perform the required actions to land on the mentioned page. Once done, go to the Network tab in the Dev Tools, right-click on any item and choose ‘Save as Har with Content’.

Now in the Recorder, chose the HAR file and give a meaningful class name to the simulation. The rest of the options left unchanged. Go on and press the ‘Start’ button. The Recorder will prompt that it successfully converted the HAR file to a Gatling simulation, so we can close the Recorder window.

Next thing to do is set up our scenario. If you open the newly created simulation class and go to the very end, you will find the ‘setUp’ call which is currently set to run the simulation for 1 ‘atOnceUsers’. We can modify this to create our required simulated traffic. Gatling provides different ways of setting up your scenario which can be found on this page. For this example, we will try out the ‘ rampUsers’ during a defined duration and we will generate 100 virtual users during 1 minute. We can do this by setting the ‘SetUp’ call to this:

setUp(scn.inject(rampUsers(100) during (1 minute))).protocols(httpProtocol)

Once the simulation is defined, we can go ahead and run the Engine class. This will prompt you to optionally enter a description for the simulation run which will be then shown in the generated report. At the end of the simulation run, you will be shown the path for the report which you can open in a browser window. This will provide you with loads of information on how your site performed against the simulated traffic.

What’s the Trend?

Once you decide which scenarios should be re-run for each new build of the site, a great way to track the trend of test results is to run your performance tests using a CI tool such as Jenkins. This way you can easily check previous runs and assess if a new build is degrading or improving the site. To make your life even easier, you can make use of a plugin which plots the results from the available test run to show graphs such as the average response time. The plugin can be found here.

That’s it? What can be improved?

If you had a quick look at the generated code you will notice that it is currently not so easy to read and maintain. It definitely needs a refactoring session. We will discuss this and more on the usage of Gatling in the next post. Until then, let us know if you have any comment or share your insight on Gatling with us!

Originally published at https://testautonation.com on 01/2019.