Load testing - Getting started with Gatling and RedLine13

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.

Free Download: Black Friday Ecommerce Guide

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.

RELATED: Everything You Need To Know About Load Testing

Less painful, almost free, web load testing

Open-source software

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.

At Queue-it, we use two: JMeter and Gatling.

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.

Cloud-based execution

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.

The vast majority of your test will be written with the Domain Specific Language of Gatling, and you will not even notice you are writing Scala code. For those special requirements, Scala is not much different than some of the functional elements of languages like JavaScript and C#.

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.

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._
class RealValueTalks extends Simulation {
val httpProtocol = http
.baseURL("http://realvaluetalks.com")
val scn = scenario("RealValueTalks")
.exec(http("IndexPage")
.get("/index.html")

.check(status.is(200)))

.pause(2 seconds)

.exec(http("LoadBackgoundImage")

.get("/img/bg.jpg")

.check(status.is(200)))

setUp(scn.inject(rampUsers(1.000) over (30 seconds)))

.protocols(httpProtocol)

}

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.)