Load Testing a Website: What Wind Tunnels and Simulators Teach Us

Load testing a website is the practice of putting artificial traffic on a site to find out how it behaves before the real crowd arrives. Motor racing teams have always worked this way. They use wind tunnels and computer simulations to explore how a design performs under controlled conditions, then correlate the results with data from the track, because a model that does not match reality is dangerous. A website heading for a busy day, a product launch or a ticket release deserves exactly this approach.

Decide what you are afraid of

Begin with the scenarios that worry you. Perhaps it is a newsletter that sends ten thousand people to one page within minutes, a sale that opens at nine in the morning, or an event listing that is shared widely. Estimate how many visitors might arrive, how quickly and what they will do. Tie it to the business: how many orders per minute must the checkout cope with? A target gives the test a pass mark.

Build realistic journeys

Real visitors do not request one page repeatedly. They browse, search, add to a basket, sign in and check out. Script those journeys using a load-testing tool such as k6, JMeter or Locust, with realistic pauses between steps and varied data. Include the heavy operations, such as search and payment, because they usually fail first. Beware of testing only the home page, which is often cached and tells you almost nothing.

Test somewhere safe

Never aim a stress test at a live system without warning, and never at a service you do not own, such as a third-party payment provider. Use a staging environment that mirrors production in size and configuration, or arrange a quiet window with your host. Tell them in advance, because a sudden surge may look like an attack. Use test accounts and test payment modes, and clean up afterwards.

Ramp up and watch everything

Increase the load in stages, holding each level long enough to see the system settle. Record response times, preferably the slowest few percent as well as the average, since it is those slow requests that frustrate real people. Watch error rates, processor and memory use on the servers, database activity and queue lengths. The first bottleneck is rarely where you expect. It may be a database query, a limit on connections or a third-party script.

Find the knee in the curve

Most systems perform acceptably until a point and then degrade sharply. Locate that point, and compare it with the traffic you expect. If you have a comfortable margin, good. If not, decide where to invest: caching pages, optimising the slow query, adding capacity or introducing a waiting room that admits visitors at a rate the system can bear. Repeat the test after each change to confirm that it helped.

Be honest about the limits of the model

Test traffic behaves more politely than a real crowd, and your test environment is never identical to production. Treat the results as a guide with a safety margin, and keep watching real behaviour on the day, with monitoring, alerts and someone ready to act. Write down a plan for what to switch off first if things go wrong, such as non-essential features.

Make it routine

Fix the cheap things first

Many sites buckle under a surprisingly modest crowd for dull reasons: no caching of pages that never change, images served at full size, a database query run on every page view, or a plug-in that calls an external service on each request. Before buying more servers, look for these. A cached home page can handle many times the traffic of an uncached one, and often the cost is a configuration setting and an afternoon of testing.

Plan the human side of the day

Decide who will watch the dashboards during the event, who can change settings, who talks to customers and who has the authority to switch off a feature. Agree thresholds in advance, such as the response time at which you enable a waiting room. A rehearsed plan and a calm team are worth more than any amount of last-minute heroics.

Add a smaller version of the test to your regular release process so that a change that slows things down is caught early. If you would like help preparing a site for a launch or an on-sale, we can design the test with you and interpret the results plainly.