Scaling for success: load testing your app for Black Friday – part 1

Observability takes its roots in the quest for preparedness. To be ready for anything happening in your application’s life, you need to be able to observe its real behavior under all circumstances.

We can see observability as a superpower. It’s not the type you develop after being bitten by some bug, but the one you give yourself using advanced technology. In a previous piece, we warned that Black Friday was coming – and it still is.

In this installment, we will see how to transition from Eddard to Tony Stark and leverage technology to your advantage in that quest for preparedness. Fasten your seatbelts, things are about to get real! We will do some load testing on our application to enforce performance under harsh conditions.

Get ready to ride the traffic wave

One of the main issues and opportunities is the massive increase in traffic during Black Friday, Cyber Monday, or any peak periods faced by your application and business. Accrued traffic should imply an increase in revenue, but your conversion rate drops for every extra millisecond your users wait for your application to respond. A crashed application leads to pure revenue loss.

Ensuring in advance that your application will sustain a qualitative user experience even during significant traffic and concurrent users will secure the success of your operations. Otherwise, you might take a bet based on a rule of thumb.

Therefore, this blog post series aims to help you set up load-testing campaigns that will allow you to validate and improve your application and configuration over time. By now, you should already have developed an observability strategy. We are enriching it with a new tool you can reuse whenever needed.

What’s your battle plan?

Your application doesn’t work in isolation. Its performance derives from the quality of its codebase and from how well the whole project is configured and scaled. Therefore, we have two angles from which to consider load testing.

The first is proactively detecting parts of your application that become flaky or throttle under heavy pressure. The second is ensuring that your application, components, and infrastructure are correctly scaled with enough CPU/RAM/workers to face the load.

You don’t have to pick one over the other, but you should do both. This is how you will future-proof your project. For that, we need to work on a development environment that is a carbon copy of your production one and a Blackfire environment with Blackfire Monitoring and Continuous Profiling enabled.

While we recommend that you use those tools only on production, the fact that we will generate heavy fake traffic restores their usefulness. They will be essential in understanding your application’s real behavior during those intense periods.

Create a carbon copy of your production environment

As we don’t want to spam our production applications with generated and intense traffic spikes, the first step is to create a carbon copy of your production environment. We need to rely on the same version of runtimes and services, with databases and storage as large as they can be, as well as all the external tools. It’s not uncommon that issues arise from struggling workers or resource-intensive periodic commands.

If you are using a Platform-as-a-Service (PaaS) such as Upsun, this is achieved as simply as creating a branch. With your Upsun project integrated with your Git repository, creating a branch leads to cloning the parent environment with all its data. This blog post describes this transformative mechanism in greater detail.

Because we love facts and transparency, I must mention that Blackfire and Upsun are part of the same company, Platform.sh. However, I am not highlighting this for PR-stunt reasons you could reasonably object to; we are convinced developers should be able to focus solely on what matters most to them, having all the rest be automated.

Focus on what matters most to you

Developers should be able to spend all of their time writing great code and building awesome apps rather than maintaining their infrastructure or observability pipelines. Upsun is truly great at making it possible.

If you don’t have access to similar cloning strategies, try your best to set an environment as comparable as possible to your production. It’s better to work with an existing approximative configuration than a perfect one that might never exist. 

Performance optimization and enforcement are achieved by accumulating a series of minor improvements. We aim for the stars and get there one step at a time.

In the next installment of this series on load testing, we will get our hands dirty and start coding load-testing files to put as much stress as needed on this carbon copy of our application. We need to assess its breaking point to push it even further while ensuring smooth operations at all times and securing the growth of your business.

To better observability and beyond

The “Scaling for success: load testing your app for Black Friday” series:

• part 1 (you are here)
• part 2
• part 3 and final