Performance Testing with Gatling: Summing up the QA Meetup
On March 20, we hosted a QA meetup at SFL and our very own Sona (Automation QA Engineer) and Hektor (Java Developer) did a presentation about performance testing with Gatling (for the first time in Armenia ever!).
But before jumping into speaking about the many advantages of Gatling, let’s highlight that we do not undervalue JMeter. Both JMeter and Gatling are really powerful and any kind of performance testing goal can be reached with the help of them both. However, like with any other tool, these two have their pros and cons and it’s all up to you to decide which one to use in a specific project.
As the web had become an inseparable part of people’s lives, it’s really important for us to develop perfectly functioning and fast web applications. The performance of the application is one of the crucial quality characteristics nowadays. That’s why we had no doubt while choosing a topic for the QA meetup. Our goal was to share the knowledge and practice gained during testing of one of SFLs biggest projects.
Before choosing the tool to be used, a proper investigation has been conducted during which many tools have been compared and evaluated.
As currently the most popular open-source tool with the biggest community is JMeter, we decided to draw parallels between it and Gatling (the tool which we use).
So let’s start!
First of all, we would like to bring the top cons of Gatling which make it an absolute winner for us:
- Gatling is an open-source performance testing framework based on Scala, which has human-readable DSL. Due to this, it will be easier to create and run your tests on various platforms.
- As Gatling tests are written as source code, it’s possible to store the tests in version control systems which enhances team collaboration, helps to keep historical changes clear and prevents us from losing the work we have done.
- Gatling is a really powerful tool. It uses Netty framework and Akka toolkit which is based on the actor model that is distributed and fully asynchronous by design. Thanks to the Akka toolkit, Gatling doesn’t allocate a separate thread for each user. Instead, all multithreading is handled by messages between actors, which allows simulating a list of users by using just one thread.
- As any Gatling project can be built using Maven, Gradle builders, it can be easily integrated into CI/CD pipelines out of box. While in JMeter, you can do the same thing but that will require more effort since you will need to set up specific CI plugins.
- Performance testing is useless without execution monitoring. Real-time monitoring allows you to keep execution under control. That’s why Gatling provides smooth integration with real-time tracking tools (Gatling Frontline, Taurus, NewRelic, etc.).
- Gatling has an integrated assertions API. It allows you to run different types of functional checks along with your performance testing. The Gatling assertions API is flexible and allows you to run all checks either for specific requests or for all requests at once.
In contrast to the above-mentioned points, Jmeter has the following limitations:
- Reports are usually displayed at the end of the test and only exist locally. There’s no built-in way to share or collaborate.
- Additional plugins are needed in order to organize CI pipelines.
- JMeter uses 1 thread = 1 user paradigm (each simulated user virtual user equals to a single thread).
During the session, we also talked about Gatling recorder, described what are simulations and scenarios, gave some details about the Gatling session, feeders, assertions, and checks.
As a conclusion, we showed some practical examples implemented using a POM design pattern.
If all this made you curious and you are motivated to start using Gatling for your performance testing then the best place to start is the gatling.io website.
About the speakers: Sona Sahakyan is an Automation QA Engineer and Hektor Khachatryan is an ex-QA engineer and a current Java developer at SFL.
Want to join SFL? Check out our openings here.
