Gatling is one of the world’s most powerful load testing tools. With over 15 million downloads of our open-source version, we’re very happy to say that Gatling is being used by some of the largest enterprises worldwide as their primary load testing tool. One of the disadvantages of this much adoption though is that many people who don’t understand the tool or lack the technical knowledge of Gatling make public assertions that there are some flaws or errors in how Gatling works. This leads to users who run into issues or make errors posting their issues on blogs, social media, or tech forums and some of these misconceptions have now been viewed by users around the world.
In customer success, we talk to a lot of existing and future Gatling users so we tend to hear the same questions over and over. In this article, we’re going to be looking at some of the questions that pertain to what I like to call Gatling Myths, addressing where they are coming from and any possible truth behind them and providing the actual truth about how they work and what you can expect from Gatling. Let’s get into the myths!
#1 Gatling has a memory leak
The Myth
"Is it true that a Gatling disadvantage is poorly managed memory utilization because it requires lots of memory for a high RPS amount?"
When you’re looking for a tool to accomplish a task, often you’ll type into Google: “best tool to accomplish ______”. From there, you’ll be shown a list of all the different tools that can accomplish a task with their strengths and weaknesses. Some of the links will be from companies that offer these tools and others will be from independent sources. Almost all of these analyses will end each description with a summary and a pros and cons list. One point that we noticed came up in a few for Gatling was that it had high memory usage and contained a memory leak.
The Truth
To get an idea of what the truth is you have to understand a bit about how Gatling is built. Gatling runs on a JVM, whose resident memory (memory used when starting programs) is slightly higher than programs compiled natively. By default, Gatling reserves 1GB of memory to ensure it has plenty of room to work. Other than that though, you shouldn’t have any memory issues. In fact, one of Gatling’s main advantages is that it can simulate an incredible amount of users with very few resources due to the way it was built. Gatling uses Akka actors and non-blocking IO in order to share threads without sharing memory between virtual users, which makes us one of the efficiency leaders in the load testing world.
#2 You need to know Scala to use Gatling
The Myth
"I’m hesitant to learn Gatling because I don’t have any Scala knowledge."
Throughout the internet when looking at sites that compare various load testing tools you’ll see that one of the cons listed for Gatling is that it requires you to create scripts in Scala.
The Truth
This myth is mostly the result of older web content not being updated. From Gatling’s inception until last year in November scripts were written using our Scala DSL. However, with the release of Gatling 3.7 last year we also introduced our new Java DSL which allows scripting in both Java and Kotlin. That still is only one half of the truth though because I would also mention that you don’t need to be a dedicated Java, Scala, or Kotlin developer to use Gatling’s DSLs. Realistically, any developer can learn how to write scripts in any of the languages offered in a few short days (although being proficient in one of them is certainly a plus). If you’re wondering which language to use, check out this post to walk you through choosing the best language for your team.
#3 Gatling has a steep learning curve
The Myth
"Compared to other no-code tools it’s difficult to use Gatling."
This might be cheating a bit to say that a no-code tool is easier to use than a tool that involves scripting is inherently true for 99% of people in the world.
However, Gatling is a tool that is built and designed for developers and if you’re reading our blog I’m going to assume you have a rough idea of who we are and what we do so…
The Truth
Gatling is designed as a load-test-as-code solution. Our products are designed for developers and to be easy to use and easy to learn for developers.
In my experience, a developer can start using the Gatling Academy, our documentation, and join our community and start creating powerful, easy-to-edit, and maintain load tests within 2 days. So yes, you might be able to create a test more quickly with a no-code solution. With Gatling though, you can still create a test quickly with our recorder and once it’s refactored with very just a few days of training you’ll be able to update, maintain, and reuse your scripts easily as code.
#4 Gatling can’t reach X requests per second or simulate X virtual users
The Myth
"I’ve heard that other tools can simulate more requests per second than Gatling."
When talking to those just starting out in load testing, often their first question is about horsepower: How many users per second or requests per second can I generate with Gatling? We’ll also often hear, “I read that this user couldn’t do this when using Gatling”.
This is a bit of a complex question, but let’s dig in.
The Truth
The internet is a big place, and Gatling has been around for 10 years. We’ve had over 15 million downloads of our open-source version in that time (thanks to all who have downloaded) but because of this, there’s bound to be some old or inaccurate reporting on the subject. It’s also something that’s hard to exactly quantify and that’s because there is theoretically no limit to the number of requests per second that Gatling can simulate. It all comes down to your machine and the scenario you’re running as not all requests and scenarios are equal.
Pivoting briefly to Gatling Enterprise, we can get a better idea of how many requests per second you can simulate in a particular scenario by using our load generator monitoring feature. Even then, if you want to add more requests per second than one load generator can manage you always have the option of deploying additional generators so there is no real limit.
On Gatling Enterprise Cloud we also have the added benefit of not limiting you to a certain number of concurrent users or requests per second based on your plan. Even with our Scout plans you’re given total access to the load generator you’re using and can use it to its full potential to test your applications.
Anything else?
I hope that this has helped answer some of your questions. Is there anything else about Gatling that you’re curious about? Are there any other myths that you’ve heard? Let us know and we’ll be sure to respond to them in a future post.
