Load testing in practice: How to find the limit before the customer does.

Every shop has a limit. The only open question is who will find it first: you on a quiet Tuesday in September — or four hundred simultaneous visitors on November 27th at 20:07 pm. The difference between the two dates is a few hours of work and a very different revenue.

The article about hosting under load discussed the infrastructure your shop needs. Today, we'll address the question that almost never gets asked: How do you actually know what it has? Not by feel, not by the host's data sheet—but by measurement.

The unpleasant lesson learned from many of these measurements: The limit is rarely where you'd expect it to be. It's almost never the RAM, often a single database query, and frequently a payment transaction that no one has ever tested under load.

Why your speed test reveals nothing about the peak

The usual process: Someone enters the shop's address into a speed tool, gets a score between 70 and 90, is satisfied, and considers the matter closed. The problem isn't the tool itself, but the question it answers.

These tools measure a visitor under laboratory conditions: one device, one connection, one location, one server that otherwise has nothing to do. Google describes this difference in detail in its documentation on the differences between lab and field data : The lab deliberately limits the variables so that results remain comparable. This is precisely why it cannot capture the one thing that matters most in December—that three hundred other people are simultaneously trying to access the same server.

A good idle speed rating isn't a lie. It's simply the answer to a question nobody asks during the Christmas season. The question isn't "How fast is my site?", but rather "At what number of concurrent visitors does it stop being fast?"

And that's not a number you can estimate. In our experience, operators' assumptions are regularly off by a factor of three to five—in both directions. There are sparsely equipped shops that can handle a surprising amount of traffic, and generously sized shops that grind to a halt with 80 simultaneous sessions due to a poorly implemented filter query.

Four tests, all called "load tests".

Before you touch a tool, you should know what question you actually want to answer. In common parlance, it's all called a "load test," but in reality, it's four tests with four different results.

The load test: Can it withstand realistic expectations?

They simulate the expected traffic load and check whether the shop stays within your target values. This is the test every shop needs once a year. The result: a yes or no to a specific number of visitors.

The stress test: Where exactly does it end?

Here, you increase the load beyond expectations until the system gives way. This is the unpleasant but most valuable test—because it provides the figure you'll need in November: the limit. Knowing this limit allows you to calculate how much advertising budget the shop can handle before it becomes a bottleneck itself.

The peak load test: Newsletter, 10 a.m., all at once

Here, the load doesn't come on gradually, but suddenly—and then disappears again. This is exactly what happens when sending newsletters, launching a discount campaign, and in the first minute after midnight on Black Friday. Two things are tested: whether the system can withstand the peak and whether it returns to a normal state afterward. The second part is often overlooked and is the more frequent cause of failure.

The endurance test: What happens after four hours?

A continuous load test sustains moderate activity over an extended period. It uncovers what a short test can't: memory leaks, overflowing connection pools, and log files filling up the hard drive. This test is for anyone whose online store crashes not in the first hour of Black Friday, but in the sixth—a pattern that occurs more frequently than it sounds.

For most online shops, the sensible sequence is: first a load test , then a stress test, and if both are successful, a continuous test lasting half a day. Peak load tests are necessary for those who launch promotions at fixed times—which is almost everyone in the fourth quarter. That this distinction is not mere semantics is demonstrated by the German-language Performance Testing curriculum of the German Testing Board , which clearly differentiates the various test types—including the question of which key performance indicators (KPIs) each can provide.

The target load: Where the number you are measuring against comes from

A test without a target value is a waste of time. "Let's see what happens" leads to a colorful chart and no decision. Beforehand, you need two figures: the load you expect and the threshold at which you consider the result a failure.

You derive the expected load from your own data, not from industry benchmarks. This takes ten minutes: Find the busiest hour of the last fourth quarter in your statistics. This is usually Black Friday evening between 19 and 22 p.m. or the second Sunday of Advent. Take the number of visitors during that hour, add your projected growth, and then add a 50 percent safety margin.

For example: 1.200 visitors in the peak hour, a planned 20 percent growth, plus a safety margin—that results in a target of approximately 2.160 visitors per hour. With an average session duration of about five minutes, that's roughly 180 concurrent sessions. This number is your target load. It's not exact, but it's well-founded—and therefore superior to any estimate.

The second number is the target value. Define it before the test; otherwise, it will be adjusted afterward. A proven approach is to keep the response time of the most important pages under two seconds, the error rate under one percent, and ensure that no errors occur during the payment process. Those who also adhere to the Core Web Vitals thresholds will have an even stricter benchmark.

The scenario is more important than the tool

This is where it's decided whether a load test is useful. Most homemade tests fail not because of the tools, but because they query the wrong things.

Why the homepage proves nothing

The homepage is the most cached page of your shop. A test that retrieves it a thousand times essentially measures the delivery speed of a finished file. Impressive numbers, but meaningless.

The bottleneck occurs where the cache isn't active: on category pages with filters applied, in the search results, in the shopping cart, in the customer account , and during checkout. These pages have to be calculated individually for each visitor—and these are precisely the ones that experience the first drop in performance.

The distribution that closely reflects reality

Don't map a single page view, but rather a path through the shop. A breakdown that works well for most product ranges: around 45 percent of simulated visitors browse categories and filters, 20 percent use the search function, 25 percent open product detail pages, 7 percent add something to the shopping cart, and 3 percent proceed to checkout.

These last three percent are the most crucial part of the test. The checkout process is the most expensive part of your system—session management, inventory checks, tax calculations, and queries to payment and shipping providers. If a queue forms anywhere, it will here. Testing only category pages will give you a good result and a nasty surprise. We've already described the inherent friction points in our article on checkout abandonment —and under load, every single one of them is exacerbated.

Two details that distort the results

Simulated visitors clicking continuously create a load that doesn't exist in reality. Build in pauses of two to five seconds between clicks—otherwise, you'll discard a perfectly good system. And let the shop warm up for a few minutes before measuring: The first visit after a restart fills caches and opens database connections; these values ​​shouldn't be included in the analysis.

Where you test: the copy, not the original

The first reflex is to test against the live shop – after all, you want to know what the real shop can withstand. This reflex is understandable, but in most cases wrong.

A load test against production generates real shopping carts, real orders, real confirmation emails, and real entries in your statistics. It distorts your key performance indicators for weeks, can tie up inventory, and in the worst-case scenario, brings the shop to a standstill during business hours—precisely the situation you wanted to avoid. The German Federal Office for Information Security's (BSI) IT baseline protection guidelines are unequivocal on this point: The module on software testing and approvals requires a test environment separate from production operations and explicitly warns against testing with real data.

For the results to be valuable, the copy must be an honest copy. Four points determine this:

E-Commerce News - Tips & Tricks Christmas business 2026: Why your Q4 will be decided in August

First, the system dimensions. Same number of processor cores, same RAM, same PHP configuration. A test system on half the server tells only half the story. Second, the data volume. A catalog with 300 test items behaves completely differently than one with 30.000—the interesting database problems only arise with a real dataset. Third, the cache settings. Disabling the cache on the test system to obtain "clean" measurements means measuring a system that doesn't exist. Fourth, the extensions. Specifically, the modules that are running live—including the three that no one remembers anymore.

Tools: fewer than you think

The question of tools is overrated. You don't need a budget to get started , just half an hour of training.

For simple measurements, a command-line tool like `ab` or `siege` is sufficient : specify the address and number of simultaneous accesses, and read off response times and error rates. This allows you to roughly classify a single category page in five minutes—but nothing more, as it doesn't map a user path.

As soon as you want to map multiple steps, registration, and shopping carts, you'll need a true load balancer. k6 describes scenarios in JavaScript and is usually the quickest way for development teams to get started; Apache JMeter offers a graphical interface and requires no programming knowledge; Locust is the obvious choice if your team already writes in Python. All three are open source and free.

Rented services only become worthwhile when dealing with loads from multiple regions and on a scale that a single computer can no longer generate—this applies to very few shops. However, a word of caution from practical experience: beyond a certain size, the bottleneck is no longer your shop, but the computer you're testing from. If the measured times increase while the shop itself shows little load, measure your own laptop.

Reading the kink: what the curve says

The result of a load test is not a value, but a shape. You gradually increase the number of concurrent visitors and observe two curves: the throughput—that is, the actual number of requests processed per second—and the response time.

As long as everything is healthy, throughput increases with load, and response time remains almost constant. Then comes the point where throughput no longer increases while response time increases: the kink. This is your limit —well before the first error message. Errors come later. Waiting for them doesn't measure the system's limit, but its collapse.

One detail determines the validity of the results: Don't look at the average. The German Testing Board's curriculum points this out precisely—the mathematical average is distorted by outliers and hides the problematic cases. Instead, consider the 90th or 95th percentile: the value that 90 or 95 percent of requests meet, respectively. An average of 1,2 seconds sounds good. But if that average is based on a 95th percentile of nine seconds, then one in twenty customers is waiting nine seconds—on a busy day, that's several hundred people.

If it has to be production

E-news for ambitious developers - read up to speed Hosting under Last: What your shop really needs in November

Sometimes there is no testing system, and the decision is: test against production or not test at all. In that case, a short list applies, and no point is negotiable.

Speak with your hosting provider beforehand—in writing. A load test looks like an attack from the outside. Without prior agreement, security mechanisms will kick in; in the worst case, your access will be blocked, and many contracts prohibit such tests. The BSI (German Federal Office for Information Security) practical guide for IS penetration tests formulates two rules for comparable tests that can be directly applied here: no testing without a written order, and if services are outsourced to a hosting provider, that provider must be included in the agreement. The same guide recommends scheduling the test period for a time with minimal disruption to regular operations.

At night, not at midday. Between two and five in the morning, the damage is minimal if the shop actually goes under.

Set payment methods to test mode ; otherwise, you'll generate real payment transactions and subsequently have to reverse them. Exclude test traffic from the statistics , either by using a fixed identifier in the call or by excluding the test IP address—otherwise, you'll be explaining in January why the bounce rate for one night was 100 percent.

And have a second person present to monitor the shop in the browser and terminate the test if necessary. A pre-agreed termination criterion avoids arguments in the middle of the test.

What you do with the result

The most common mistake after a load test is to immediately order a larger server. This sometimes helps, but it's an ongoing expense and usually only addresses the symptom rather than the cause.

The proven order is: first cache, then code, then hardware. First, check what is actually being cached and why certain pages are bypassing the cache—this is where the easiest improvements lie. Then look for the one slow query: In almost every load test we monitor, there's a single request that causes a disproportionate amount of wait time. Often it's a missing index, filter logic using too many attributes, or an extension that loads data on every page that no one sees. The article on typical bottlenecks in online stores lists the most common culprits.

Only when the cache and code are clean is hardware the right answer—but then with the stress test results in hand, not just a gut feeling. If the limit lies in the shop's architecture and not the server, that's a different discussion: We addressed that in our article on scaling and custom development.

And repeat the measurement after every major change: A load test is a snapshot in time, and the expansion from October can halve the limit measured in September. The pre-peak-season technical check includes a checklist for everything that needs to be inspected.

Conclusion: A number that makes decisions possible

A load test isn't a technical exercise, but rather the acquisition of a single piece of information: At what number of simultaneous visitors does your shop become slow? Knowing this number will allow you to make different decisions in November – regarding your advertising budget, the timing of your newsletter, and whether to launch a promotion at midnight or 10 a.m.

Those who don't know the system are simply hoping for the best. This works surprisingly well for many years, and then not at all for a year—and that one year is what you remember. The best time for the measurement is now: not because September is some magical month, but because there's time afterward to rectify the findings. A load test in November will only produce well-documented panic.

Where is your limit?

Do you know the figure for your shop — and when was it last measured? My guess is that most people don't, and that's perfectly fine as long as they know it.

The question that I expect to elicit the most interesting answers to is: Which part of your shop gave out first during testing? In our case, it was once a country selection screen during checkout that loaded a list of 40.000 postal codes every time it was accessed—unnoticed for years because, under normal circumstances, no one was ever in that area at the same time. If you've found something like that, let me know—these kinds of issues aren't documented anywhere.

If you would prefer to have the test performed by us: We can handle the measurement and evaluation as part of our support and maintenance services . For anything else, please contact us via the contact page.

This post is part of our Q4 series. Every Tuesday, a new post will be published here to help you prepare for the peak season. Next week: Payment options for the peak season — what first-time shoppers can expect in December.