There are many open source tools and paid solutions to perform load tests efficiently. As Loadium until now, we supported Apache JMeter and Selenium-based tests for load testing. Gatling, a load test tool, is on the market for a few years and it’s a mature performance test tool to use. In the near future, we are going to support Gatling tests. Let’s discuss the pros and cons of Gatling together. If you want to add more please feel free to add comments below or shoot us a message through our contact page.
First, it is an open source load testing framework for your web application and web service tests. It’s very easy to install Gatling into your local machine. Scenarios are implemented with a simple domain specific language (DSL). In case you are familiar with the DSL type testing framework, it will be very easy to adopt Gatling to your performance tests. You can generate readable and easy to maintain performance test code.
Pros & Cons of Gatling
Pros of Gatling are
- High performance; you can inject more virtual users in a local machine compared to JMeter
- Scenario recorder is very user-friendly and creates easy to read DSL scenarios
- Great visual HTML reports
Cons of Gatling
- Limited Protocol Support. As you know JMeter has over 20+ protocol support with the plugins etc.
- IDE, you only have a recorder as UI. You should do some coding for JSON, XML or CSS operations.
Actually, we cannot say those are some cons but there is some missing stuff compared to JMeter. Gatling is more of a developer/QA tool as of its nature.
Tech Stack Behind Gatling
- Server-sent events
Gatling’s installation process is simple and doesn’t require machine-by-machine basis installation.
Gatling projects can be started like any other Maven project. It has its own archetype and gives you a good starting point.
Gatling is built on Scala, Akka, and Netty. Scenarios should be developed by Scala development language. So that’s another language to learn for some of us.
Gatling also provides a visually rich report with full of data to tell us what’s going on with the application under test.
You can easily integrate Gatling tests with Jenkins even if you don’t use Loadium or similar cloud-based products.
You can execute your Gatling tests with the help of maven-plugin and Gradle-plugin.
Scenario Architecture of Gatling
Basically, load testing scenarios can be structured in 4 different parts:
- HTTP protocol configuration
This is the base URL that runs against your tests. You can also do some global configuration like user agent, language header, connection, and so on.
- Headers definition
As of all HTTP requests, you need to define headers with a request that will be sent to the server. Sometimes you might need them but for a realistic load testing, the headers add a bit of a load on servers that are testing.
- Scenario definition
The core of your test! A Scenario includes a group of actions (like GET, POST, etc.) that are executed to simulate user’s interaction with the application. You can find information about HTTP request on our previous article.
- Simulation definition
This is where you define the behavior of your real users. You define the load (number of users), the ramp-up and execution time that concurrently executes your scenario.
Then all you need to do is to execute your test from the command line client. Then you have the HTML report to analyze the response times of your request.
Those are the basics of Gatling. We’ll discover more in our next blog posts.