7 Load Testing Tips to ensure a Successful Black Friday

The easiest way to get up and running in your chosen build tool as quickly as possible is to clone the official Gatling demo repository for your chosen tool, and then start adding your own code to that:

• Gatling Maven Plugin Demo
• Gatling Maven Gradle Demo
• Gatling SBT Plugin Demo

Tip 2 – Start with a Simple Scenario

When starting out, it’s important to keep things as simple as possible. Let’s see how to write the most simple of testing scenarios in Gatling, where we simply load the homepage of our site.

Note that we will be writing some Scala code in this article, or more specifically Gatling code. If the thought of writing code is uncomfortable to you, don’t fret! This language was made easy for that purpose. 

Gatling ships with a powerful DSL (Domain Specific Language) that makes it simple to construct a detailed load test by writing simple, meaningful and verbose words and phrases.

Let’s look at one of the most simple Gatling scripts you might start out with to prepare your web application for Black Friday:

Our entire load testing script fits in these few lines. However, let’s break it down line-by-line. We start by importing a couple of packages, which contain all the language definitions needed to make Gatling work:

Next, we define our Black Friday load test simulation class (called BlackFridayLoadTest) and we extend this from the special Gatling Simulation class:

Inside the simulation class we just created, we now define the protocol we want to use (HTTP in this case) and supply the default parameters. For our script, we are simply supplying the base URL of our web application:

Now we can define the steps of the scenario itself. These are the steps that the virtual user will take on our website when we execute the load test. Since we are aiming for the simplest test possible to help us prepare for Black Friday, we are simply loading the home page here:

Our scenario above only loads the homepage of our web application. However, for your Black Friday load test you will likely want to modify it to reflect the expected behavior of your end-users. 

For example, as users will likely be searching regularly for the best deals, you can expect to see a significant increase in the number of searches being performed in your application. You should therefore modify your scenario appropriately so that users perform more searches than normal.

Before we continue, let’s explain the differences between a scenario and a simulation in Gatling terminology:

• A scenario describes the steps a virtual user takes through the system i.e. load the home page, click on the product, add to cart etc.
• While the simulation is the definition of the load profile that will be executed for the test, i.e. the number of users, the throughput and arrival rate of those users, the test duration etc.

With this terminology in mind, we can look at the setup block of our script, where we define the load simulation:

The load simulation above will simply run our scenario with a single user. It is a useful default to have in place when creating and debugging your Gatling script. When you are ready to run an actual simulation based on your expected traffic for Black Friday, you will update this setup block appropriately as seen later on in this article.

With this basic script in place, let’s move on to our next tip:

Tip 3 – Create Accurate Scenarios

The Gatling recorder acts as a proxy, capturing the traffic that is generated as the user performs various actions on the website, such as searching for a product or going through the checkout process. This generated code is then turned into a Gatling script, which we can use for our scenario.

In addition to the Gatling Recorder documentation, be sure to check out the Gatling Academy for detailed video tutorials on using the Gatling Recorder to create Gatling scripts.

Now that we have a Gatling script in place with accurate scenarios, we need to think about the next point:

Tip 4 – Execute Different Types of Load Test

Think about the different scenarios and situations your system might likely find itself in during this busy Black Friday period.

Going back to our original BlackFridayLoadTest simulation that we created earlier, we defined the following:

This load test profile is suitable for when we are creating and debugging our Gatling script. But if we want to make sure our web application is ready for a busy Black Friday, we need to define a suitable injection profile!

Remember that the injection profile is simply a chain of rules, which will be executed in the provided order, to describe the rate at which virtual users execute their test scenario (or “user journey”) through the system.

We need to ask ourselves how we expect users to arrive at our system during the Black Friday period. Do we expect users to arrive at specific time periods throughout the day, or is it more likely to be a steady stream of traffic? 

If one of our competitor’s sites were to go offline during the Black Friday period, we could reasonably expect a sudden surge in traffic. Will our system be able to cope with that?

Are we launching a special offer during this promotional period, such as a Black Friday Countdown? When word spreads on social media or otherwise, will this lead to a steadily increasing amount of traffic and load through the system?

Considering these questions and situations will help us to define our injection profile, also known as a type of test. Let’s look at three of the most common ones here:

Stress Testing

A stress test, also referred to as a “spike test”, represents a sudden surge in demand on the system. During this period, we can expect many new users to arrive at the system in a short amount of time. In Gatling, we could define this injection profile as follows:

From a Black Friday perspective, we might expect one of these surges to occur if one of our competitors suddenly went offline. Alternatively, a viral social media post or some other form of advertising that alerted customers to a potential offer could see this scenario occur.

To achieve this level of load and throughput in our test environment would likely require multiple load injector machines and support for distributed load-testing. Gatling FrontLine, the Enterprise version of Gatling, would enable us to execute such a test with just a few clicks whilst still using the script we created in the open-source version of the tool.

Soak Testing

Black Friday is a long event, typically running for three days across the US Thanksgiving weekend. In fact over the last few years, there is a trend with companies running Black Friday events of longer periods, with some even lasting a month or more.

Soak testing allows us to ensure that our system performance remains stable and consistent for longer periods of increased load. The goal of this type of test is to identify problems in the system like memory leaks or high CPU utilisation, that only occur over a longer period.

A simple Gatling injection profile might look like this:

If we wanted to add a period of ramping-load onto the system before staying at a steady rate, we could combine two Gatling DSL methods:

Capacity Testing

The idea with Capacity testing is to keep increasing the load on the system until we find the “breaking point”, where transaction response times greatly increase and errors begin to occur.

Having identified this breaking point in our system, we can be confident of handling the expected levels of traffic that Black Friday is likely to bring through our system.

To write a capacity test in Gatling, we can run at a constant throughput for an arbitrary amount of time, then ramp the load to an increased level before continuing with another constant load. 

Our injection profile might look something like this:

Instead of having to write out cumbersome code to repeat this process many times, we can take advantage of the Gatling DSL to write an expressive test for us:

Graphically, this scenario would look like this:

Tip 5 – Measure Response Times as Percentiles

Beyond looking at errors and the error rate we see in our load test, the key metric to monitor is transaction response times. These can be monitored broadly in two different ways:

• Response time as an average – typically measured as the mean response time
• Or as a percentile

Although using the average to measure response times can be tempting, it is an inferior approach, as it can hide the true response time of your system for the majority of your users.

Measuring response times in percentiles is far superior when it comes to load and performance testing. These enable you to give an accurate reflection of what performance is like for the given percentage of your users. In our load testing results, if the 99nth percentile was shown as 100ms, this means that 99% of users experience a response time of 100ms or less.

Presenting metrics to stakeholders in this way is of far greater value. Remember that we want to make sure that the vast majority of users to our site have a great experience, with fast load times and good performance.

Tip 6 – Execute a Distributed Load Test

Assuming you have an application that is internet-facing, your traffic can and will come from many sources across the globe. Although starting out your load testing from a single load injector is a good start, and can easily be achieved with Gatling Open-Source, it is not sufficient to simulate a true real-world load test.

In order to generate the traffic for such a realistic load test, the traffic must come from multiple sources by using a distributed load testing infrastructure. This can typically be achieved by having multiple cloud-based load injectors running across a broad range of geographical availability zones.

Executing a load test of this nature might sound both expensive and cumbersome, but that isn’t actually the case. Using Enterprise, Gatling’s business tool, you can take your existing Gatling test scripts that were created with the open-source version and run a distributed load test across a range of availability zones in the cloud with just a few clicks.

Gatling FrontLine is available on demand. This means your load testing infrastructure is only deployed and active for the period of your load test executions, significantly reducing the cost of load testing when compared to other solutions.

For more information on Gatling FrontLine, including a demo and free trial, check the Gatling FrontLine website.

Tip 7 – Don’t treat Black Friday as a one-off

Black Friday is a perfect reason to start investing in your load testing efforts, but once the event is over you shouldn’t stop there. Surges in traffic or unexpected load on your system could happen any time of the year, and your system needs to be ready to handle this.

Developing load testing scripts with Gatling open-source is an excellent place to start, as we have seen in this article. Once you have those scripts in place and are ready to take your load testing to the next level with distributed load testing on demand coupled with detailed real-time reporting, Gatling FrontLine is the natural solution to progress to.

A minimal investment in high-quality load testing with Gatling FrontLine is highly worthwhile, as although you can never know when that next spike in traffic is likely to come, you want to make sure your system and your business are ready to handle it and take advantage.