Web load testing used to be painfully costly and complex, leading many to skip it. But load testing is a critical step to gauge and ensure website performance. With the open source tools and cheap cloud-based execution services now available, there’s no good reason to neglect load testing. I use Gatling and RedLine13 for less painful, almost free web load testing, and here’s how you can too.
Web application load testing has historically been expensive and difficult. Software from commercial vendors cost thousands of dollars. Buying equipment and maintaining it would set you back even more. The software was often complex and the learning curve was steep.
This process was so painful that load testing was often skipped.
But load testing is critical. It helps identify issues in your software that will not show up in your functional tests.
Skipping load testing is why the majority of our customers have no idea when or why their software breaks.
And with new less painful, almost free tools, the old excuses don’t apply.
With cloud computing, load testing at scale has become available to anyone. You no longer must invest in hardware to run your test. With a credit card and a few clicks, you have all the computing power you will ever need.
That said, with this distributed setup of short-lived test nodes comes complexity— management of node life cycle, software installation, test distribution, and collecting results, to name a few examples.
Several SaaS services like BlazeMeter have emerged to reduce this complexity. One of them, RedLine13, stands out from the others by being almost free. All you need to pay for are the AWS EC2 instances you use in your own account. For a large test, this is typically less than $5 USD per hour.
At Queue-it we leverage RedLine13’s cloud-based execution to run open source web load testing tools.
It works like a charm. Here's how.
Less painful, almost free, web load testing
If you have been looking at software from commercial vendors, you already know that it is expensive.
But don’t despair. There are open source alternatives that have been proven to be great alternatives.
JMeter has been around for ages. It is one of the most-used tools for load testing, and it has a huge community. It offers a graphical user interface for setting up and executing your tests, as well as viewing the results.
In Gatling, tests are written in Scala code, tests are executed from the console, and results are generated in HTML.
In my experience with the two, and as a developer, in Gatling vs JMeter I choose Gatling.
The benefits of having a complete programming language at your disposal over the limited functionality of the JMeter GUI are countless once you get to the more advanced requirements of your test. In my experience, it is also easier to scale and distribute your test environment with Gatling.
If you have tried to execute a load test in a distributed environment, you know that it is painful.
You need to deploy your test to multiple servers. Then they need to execute simultaneously. Finally, you need to collect the results of the test and visualize them. While you can do this yourself, it is a lot less painful to use a SaaS service.
Services such as BlazeMeter do this well, but still come with a cost that is a bit painful. RedLine13 is a free load testing service that allows you to run your tests with your own AWS spot instances. Although spot instances are not free, you will be able to run a test with thousands of concurrent users for a couple of US dollars.
So, there you have it. Almost free web application load testing, with less pain.
Now, how to get started?
RELATED: Load Testing vs. Stress Testing: Key Differences, Definitions & Examples
Getting started: Load testing with Gatling and RedLine13
The awesome Gatling.
Gatling is a fairly new load testing framework written in Scala. Yes, Scala….
Yes, you will be writing your tests in Scala…. Yes, it is a functional language.
Please, do not panic – it is awesome.
I have been setting up load tests in JMeter for some years, and as a developer I often run into some special requirement that the UI and XML definition of JMeter lacks. This is where I really start feeling the pain and have to come up with all kinds of workarounds.
In Gatling, you have the full programming language at your disposal, and it is just like writing a unit test. You can do anything.
Once you have your test as code, you start benefiting from improved readability, maintainability, and tools like version control that you know from unit testing.
Another great benefit of Gatling is the way virtual users are handled. In JMeter, each virtual user will require a thread. In Gatling, virtual users are just messages handled with Akka, which scales much better. At Queue-it, we need to perform load tests with hundreds of thousands of concurrent users, which is close to impossible with JMeter.
When I started with Gatling, I could not believe how painless it was. These days, I provision 25,000+ concurrent virtual users on a single test server, where I would have a maximum of 2,000 on JMeter.
There are lots of valuable resources on how to get started with Gatling here, so for now, I will just show you this script which we will use with RedLine13.
Notice how readable the script is. I think we can agree that it:
- does a get request to the index page
- verifies the OK response code
- waits 2 seconds
- does a get request to get the background image
- verifies the OK response code
- runs the test with 1,000 virtual users over 30 seconds
Running the test will produce a report like this.
Now that we have our test, let us run it at scale. In this video, I will show you how easy it is.
I can’t underscore enough how important load testing is. It’s like a dress rehearsal for your website performance. You need to understand how it will perform when real visitors start to hit it in big numbers.
Running load tests will spotlight the bottlenecks in the customer journey on your website. Once run, there are many paths you can go down to address the bottlenecks you find.
You might look for other ways to build performance into your web application.
You might change business processes to align with the technical reality of your website.
You might leverage an online queue to protect against overload of third-party systems like payment gateways.
You’ll likely need a multi-pronged approach.
But at least you won’t be in the dark.
Written by: Martin Larsen, Queue-it's Director of Product, MScIT
(This post has been updated since it was originally written in 2016.)