MY EXPERIENCE WITH GATLING

If you haven’t heard about Gatling, here’s your chance to get acquainted with it!

A few months ago, I was called to help on a Performance time-fix project, where I put my skills to the test with this code-like scripter.

I was assigned to a time box project where we needed to run as many performance tests as we could, detect problems, do the improvements, run the tests again, satisfy the customer, keep both parties happy, THE END.

At that moment, my only link or knowledge of Gatling was just of its name. I had read something and played a bit with JMETER and thought: well, probably it’s pretty much the same. But soon into the project I realized, that they were VERY different.

First of all, if you are still asking yourself what it is: in a nutshell, Gatling is code-like scripting that enables you to easily maintain your testing scenarios and automate them in your continuous delivery pipeline. With only a few machines, you can simulate hundreds of thousands of requests per second on your web application and get high-precision metrics.

One cool thing about Gatling is how easy it is to get started. It gives you the option to get a bundle: the most common thing you need to run a straightforward test. The other option is getting it from Maven, like we usually do on big projects.

I was very lucky, since Gatling was already setup and my main task was to create the simulations we needed, run them, analyze, help to make decisions to improve the actual performance and then re-test.

Another cool thing about Gatling is the simple way you can create Simulations, apart from the fact they are written on Scala (it was also my first time using Scala, and found it was not hard to learn), it is very easy to read and write scenarios. However, I strongly recommend to be sure about what you need to test. You need to understand correctly how Gatling creates users, concurrent user behavior, and what Gatling defines as “users”. The latter may lead to misunderstandings or, worst-case scenario, you will lose lot of time trying to figure out what is going on with the results you are getting. In conclusion, be sure what test cases you really need to run ( the exact steps ) and be sure you know and understand how Gatling defines users (it will help to play around with some executions and see what happens).

Back to my story.

Gatling was already setup, and one simulation was created, so I started from there, re-defined it as we needed and started with the executions. The executions were the second tricky part for me because I was hoping to just run something local like I was used to, but the reality was another. The way we ran the tests was particular: we had to connect to a remote machine (a simple linux server machine), execute the simulations by command line, and watch the logs from there. One of the devs from the team opened a port from that computer to our internal network, so the Gatling html was available to us as evidence for the analysis.

After several executions we finally identified some problems, and managed to solve them as fast as we could to re run the tests. It may sound very easy, but it was not the case. I clearly remember spending almost a week trying to figure out what had actually happened, to then find possible solutions, inform the client, make necessary changes and of course re test.

On one hand, it was a bit stressful, because the executions took time, and if we made a mistake that would have mean we would have to re execute, again and again. On the other hand, it was rewarding to see that the changes we made were successful and helped us to move on. By the end of the assigned time, we managed to almost reach the client’s objective.

What did I learn from this experience? Well, to be really honest, I learned mainly how Gatling works: how a test is made, how to execute it, what things to consider before running simulations. Although I don’t consider myself an expert, I know for sure I learned the basics and more. Also, I learned what things you may consider when dealing with Performance testing, and what things, as a QA engineer, you may propose or start doing.

What should I have done better? At some point when issues became downright technical on subjects I didn’t have a clue, I decided to take a step back and let the developers take control. In retrospect, I should have been more proactive and perhaps read, search, helped out more when such cases arose.

My final three insights for you, my readers, are:

1- Thanks for reading about my experience! I sincerely hope you found it useful.

2- If you are interested on starting Performance testing, take a chance with Gatling.

3- Share your experiences!