Why planning for “Big” traffic matters | Acro Commerce
Becky Parisotto


Becky Parisotto

, Acro Commerce Alumni

Posted in Digital Commerce, Software & Development

April 20, 2021

Why planning for “Big” traffic matters

Over the last few months, many companies have discovered that they did not have a response plan for their web properties regarding performance and scalability. Emergency response plans are important not only to ward off malicious attacks but also to handle massive traffic spikes when your product or service is suddenly in very high demand.

As the world adjusts to the new reality of staying at home, working from home and schooling from home, our clients are seeing huge traffic spikes and demands being placed on their servers, sites and teams. Being ready to flip that switch when traffic scales up, without sacrificing performance or having your site go down, can be accomplished with a few strategic actions.

Why planning ahead for the spike is necessary

Technical planning takes many forms, from architecture and security to development and integrations. In order to successfully navigate high-traffic times, planning would have needed to take place months previous. You need to have a playbook in place on how to “scale up” when the time arrives.

If you got caught unprepared, you’ll have to use short-term fixes, stop-gaps and human interventions. Keep on with these options, as they are your only bet right now.

But what can you do to make sure that you have a process in place if you ever need to flip the traffic volume switch on again? Here are a few tips on how to ensure you can support your customers when they need you more than ever.

3 things you can do to prepare your website for traffic spikes

Again, these suggestions are for what to do moving forward, not short-term fixes for what you may be experiencing with extra load currently. These are tips to build out a future strategy to ensure stability in years to come.

Disclaimer: This advice is being provided by a non-technical person! If you’d like to get into the development and DevOps weeds on any pointers you may read below, please reach out to us for an analysis with a highly skilled specialist in any of the fields of practice touched on.

To be fully prepared, you need to:

1. Conduct load testing

New call-to-action

In the world of ecommerce, “load” means traffic volume, or the number of users visiting your site at once. And “testing” means general modelling of this load in a simulated environment.

The exercise sounds simple: you simulate multiple users accessing the site concurrently. You do this by writing a series of scripts specific to your server and website, and the expected actions of your visitors. There is a toolbox available that includes secondary programs to “fake” these high traffic volumes, and it typically requires a specialist developer to complete this task.

Load testing might sound a little boring or a little expensive, but it matters. If you don’t know what volume of traffic your current site and server can handle, you cannot create a plan to react quickly as volumes climb.

Having proper load testing completed allows you to know how big (and expensive) your day-to-day server and hosting environment should be, and how far you can push it before you need to size up on the fly during high volume times.

A few areas of your architecture and setup that you should consider and design load tests for are:

  • Application server(s) or software
  • Database server(s)
  • Network
  • Client-side experience
  • Load balancing between multiple servers

From your load testing, you should know with certainty how many concurrent users your site can handle while still maintaining performance benchmarks and allowing your customers to complete purchases online.

2. Assess your hosting setup

No company thinks about their hosting until hosting is a problem. I’m talking strictly about performance and scalability in this case (not security, cost, or any other variables). When your site is suddenly an “essential service,” your servers need to scale up and stay up.

This is tied to the above point of load testing. Having an action plan to scale up first starts with knowing:

  • What type of setup do you have (i.e., Is it modern? Is it a cloud-based setup? Can we scale in real-time?)
  • Where your current setup maxes out traffic-wise through adequate load tests

It’s better to focus on a flexible cloud setup overall than it is to focus on a “bigger” setup that doesn’t scale. There is no sense in having idle resources sit there waiting for traffic volumes in the case of potential visitors.

Instead, ensure that you're using a globally recognized hosting provider with adaptive and responsive resources so when the time comes to flip the switch for heavy traffic, you can do so with ease.

3. Perform server monitoring

The natural next question that comes from load testing and server setup is: how do you know if your site is reaching its tipping point while under heavy traffic? We don’t want to wait for the site to go down and the frustrated customer calls to come in. We want to stay one step ahead of them.

This is where server monitoring comes into play. You have your load testing done, so you know the max targets you’ll be looking for. You have a clean, sexy and flexible server live. How do you know where this server is at usage-wise based on traffic stats? Server monitoring.

Make sure your scale-up procedure involves the consideration and budgeting for proper server monitoring tools. These are tools such as Prometheus or New Relic. Server monitoring software gives the technical staff a nice dashboard view, or a command center if you will, that shows them which parts of your server are meeting their max loads from high traffic in real-time, and allows you as the business owner to react to these specific technical needs in order to scale the proper areas of your server.

This sounds like a small detail, but it’s not. It keeps you from having a lot of disappointed customers when the site goes down. It also saves you a bunch of money, since you’re not throwing cash at your server in a panic; instead, you’re strategically scaling up the very specific sections of your architecture that are maxing out.

Server monitoring gives your team detailed readings of how the system’s resources are being used in areas specifically like:

  • CPU usage
  • Memory consultation
  • I/O
  • Network
  • Disk usage

Monitoring can be tethered to alerts, so your phone will buzz if your resources are getting into a danger zone. This allows you to be ready to adapt instead of reacting.

Conclusion and next steps

The security provided by these simple but essential steps will allow for your company to excel in times when other organizations are finding themselves in crisis mode due to unexpectedly high traffic volumes. We often cannot predict when we will need to turn these plans into action, but it is best to have invested in the playbook to do so. That way, when the time arrives, you can simply execute.

This style of planning is not something most companies would staff for, no matter the size of the organization. It’s more common that these tasks are performed by consultants and specialists, and then the manual is turned over to the team along with training, in order to execute as needed.

If you’d like to see an example of performance testing, this article is worth checking out. Our CTO, Shawn McCabe, wanted to see how well Drupal Commerce, an open source ecommerce platform, could scale under some extreme traffic requests. This experiment was testing a platform, not a specific website, but the process would be very similar.

If you’d like to speak to a performance and scalability insights analyst at Acro Commerce instead, we’re happy to set you up for a complimentary consultation to make sure your plans for big traffic volumes are adequate and underway. Click the link below to get started.

Let's talk about your project | Contact us | Acro Commerce

Editor’s Note: This article was originally published on April 20, 2020, and has been updated for freshness, accuracy and comprehensiveness.