A sales day is not a normal operating day. When a newsletter goes out, a discount campaign starts, or Black Friday reaches the calendar, a multiple of the usual load hits the same infrastructure -- at exactly the moment when every outage is most expensive. German online retail is set to turn over roughly 92.4 billion euros (Handelsverband Deutschland) in 2025, up four percent. That demand is not spread evenly but concentrates into a few hours: the sales days around Black Friday and Cyber Monday alone account for about 5.8 billion euros (Handelsverband Deutschland). This is exactly where load testing comes in. Before the event, it answers the question the first big rush would otherwise answer -- does the shop hold, or does it break? This article deliberately sets itself apart from ongoing performance monitoring and from the plugin audit in day-to-day operation: this is not about daily operations, but about proactive capacity planning six to eight weeks before the peak.
Why Peak Load Is a Risk of Its Own
The annual figure hides how unevenly revenue is spread across the year. The bevh puts German e-commerce goods revenue for 2025 at around 83.1 billion euros (bevh), and in the high-revenue months of October and November alone consumer online spending rose 2.9 percent (bevh) year over year. For the individual shop this means: on a few days long since marked in the calendar, a disproportionate share of the annual revenue is earned. The marketplace environment sharpens the dynamic further -- marketplaces now account for around 57 percent (Handelsverband Deutschland) of online revenue, and a campaign placed there can direct load onto the connected shop within minutes.
Under load, the whole application rarely breaks at once. The most expensive paths come under pressure first: product search, the cart and the checkout with its database writes and payment calls. As response time rises, conversion drops measurably. Google reports that bounce probability increases by 32 percent (Google) when load time grows from one to three seconds. The lever also works the other way: a Deloitte study shows that just 0.1 seconds (Deloitte) of faster load time lifts retail conversion by an average of 8.4 percent (Deloitte) and average order value by 9.2 percent (Deloitte). On peak day this relationship decides the outcome -- and a full outage costs, by Gartner's estimate, an average of roughly 5,600 US dollars (Gartner) per minute.
The Peak Reveals What Stays Hidden in Everyday Traffic
Load Testing Is Not Performance Monitoring: the Distinction
Three disciplines are often confused, even though they answer different questions. Ongoing performance monitoring watches real operation and raises an alert when metrics fall out of range. The plugin audit searches the existing stack for extensions that cost performance permanently. Load testing, by contrast, is a one-off, planned intervention ahead of a known event: it puts the shop under a controlled multiple of the expected load in order to know where the limit lies in advance. All three belong together, but only load testing answers the capacity question before real customers ask it.
| Dimension | Ongoing performance monitoring | Load testing for peak traffic |
|---|---|---|
| Timing | Continuous during live operation | One-off and planned, weeks before the event |
| Core question | Is the shop running cleanly right now? | Does the shop withstand a multiple of the load? |
| Load | Real users in real time | Controlled, simulated peak load |
| Result | Alert on deviation | Known breaking point and capacity plan |
| Purpose | Detect problems early | Prevent problems before the peak |
The consequence is a clear division of labour. Monitoring and audit keep everyday operation stable; the load test prepares the exception. In performance maintenance we therefore plan the load test as a standalone building block ahead of every foreseeable revenue peak -- not as a reaction to an incident, but as a precaution whose result is a solid number: the load at which things get tight.
The Timeline: Six to Eight Weeks Before the Event
A load test just before the peak is better than none, but it wastes its most important benefit. The value comes not from the test itself, but from the time it leaves afterwards for corrections. Testing six to eight weeks ahead leaves room to fix the bottlenecks you find, to roll out the change cleanly through a planned maintenance window and then to test again. Measuring only in the week before the event finds the same problems -- but leaves no calm time to solve them.
- Week minus 8: Estimate the expected peak from last year's data, planned campaigns and growth, and set a buffer.
- Week minus 6: Run the first load test against a production-like environment and determine the breaking point.
- Week minus 4: Fix the bottlenecks found -- caching, database, autoscaling thresholds -- and repeat the test.
- Week minus 1: Dress rehearsal at target scale, including the scaling plan and an emergency rollback.
- Event day: Scaling active, monitoring sharp, defined response paths for the unexpected.
One Test Is No Test
Defining Realistic Scenarios With a Buffer
A load test is only as meaningful as its scenario. Merely hammering the home page says little about a shop that fails on peak day at search, cart and checkout. The scenario has to reproduce the real user flow -- including the expensive write paths that are most likely to back up under load. The basis is your own data: the curve of last year's peak, the planned reach of the campaign and a realistic growth rate. Anyone who knows their own shop's downtime cost can weigh the effort of the test clearly against the risk.
- User mix: weight the shares of browsing, search, product detail, cart and checkout by real behaviour.
- Load ramp: raise the number of users step by step instead of starting at full throttle -- this exposes the knee point.
- Think times: build realistic waits between clicks, otherwise the test overstates server load.
- Write load: model orders, payment calls and stock bookings, not just read access.
- Third-party systems: account for payment providers, shipping APIs and feeds that can themselves become the bottleneck under load.
Not Just the Home Page
Above all stands the buffer. The target of the test is not the expected peak, but a multiple of it. In practice it has proven effective to test to two or three times the forecast load (project experience) -- because forecasts are wrong, viral effects cannot be planned, and a reserve above expectation is the difference between a tight and a relaxed peak day.
Determining the Breaking Point
The real insight lies in the breaking point: the load at which response times run out of range or the error rate rises. You find it by raising the load in a controlled way until the shop gives in, watching closely which resource is exhausted first -- database, application server, cache or a connected third-party system. This one number turns gut feeling into planning. Particularly revealing is transaction monitoring of the checkout under load, because reading and writing bottlenecks show most clearly here.
Load test
The shop is loaded up to the expected peak plus buffer -- it checks whether the target scale is carried cleanly.
Stress test
The load is raised beyond the buffer until the shop gives in -- this makes the breaking point visible.
Soak test
Moderate load over hours reveals memory leaks and slowly filling resources that short tests miss.
Spike test
A sudden jump in load, as during a newsletter send, checks how quickly scaling reacts.
# Vendor-neutral load-test scenario: stepped ramp beyond the buffer
# Target scale = expected peak x 3 (buffer included)
scenario: peak_checkout
stages:
- duration: 5m # warm-up
users: 200
- duration: 10m # normal load
users: 1000
- duration: 10m # expected peak
users: 5000
- duration: 10m # buffer: up to the breaking point
users: 15000
user_flow: # weighted by real behaviour
home: 10%
search: 25%
product: 30%
cart: 20%
checkout: 15% # write load, the most expensive path
thresholds: # abort if exceeded
response_p95: 800ms
error_rate: 1%The Value Lies in the Number
Cache and Autoscaling Strategy
There are two complementary answers to a breaking point that is too low: reduce the load per request and add capacity. Reducing starts with caching, because the fastest request is the one that never reaches the application server at all. Shopware explicitly calls the HTTP cache a must-have for every production system (Shopware Documentation) -- a fully cached page view costs a fraction of a dynamically computed one. Only once caching is exhausted does additional compute capacity pay off.
HTTP / full-page cache
Serve whole pages from cache so requests never load the application server in the first place.
Object cache
Keep frequent query results in memory instead of fetching them from the database on every request.
CDN for assets
Distribute images, scripts and stylesheets over a content delivery network and relieve the origin server.
Autoscaling thresholds
Start additional instances based on metrics from the load test -- not set by feel.
Database capacity
Size the connection pool, indexes and read replicas for the write and read load on peak day.
Queue decoupling
Offload non-time-critical work such as emails and feeds into a queue instead of handling it in the request.
Cache Before Capacity
Autoscaling is effective, but not a set-and-forget. New instances need time to boot -- with a sudden jump in load, that delay can itself become the bottleneck, which is why thresholds should deliberately trigger early. Above all, the database does not simply scale along: it is the classic bottleneck, and additional application servers put even more pressure on it. And embedded payment and script resources also belong under load testing -- as described in the article on PCI DSS and script monitoring of payment pages, a slow third-party script can throttle the entire checkout.
After the Peak: the Scale-Down
The load test does not end on event day. What was scaled up for the peak should be scaled back down in an orderly way afterwards -- otherwise the shop pays permanently for capacity it needs only on a few days. Just as important is to preserve what was learned: the test report, the observed breaking point and the actual peak figures form the basis for the next campaign. That way every peak becomes a data source for the one after. Continuous uptime monitoring then takes over everyday operation again and reports if the scaled-back environment does hit a limit after all.
- Scale down to the normal level in a controlled way instead of letting it run unattended.
- Check costs: cancel short-term booked capacity and restore the regular sizing.
- Document the test report and the actual peak figures -- as the starting point for the next campaign.
- Update the baseline and runbook so the next load test sets up faster.
- Adjust monitoring thresholds to the insights gained during the peak.
A peak day that nobody noticed as an exception is the real success -- achieved through work that happened weeks earlier.
From Simulation to Peak Readiness
The individual building blocks mesh into a fixed sequence: estimate capacity from data, test with a buffer, determine the breaking point, follow up with caching and scaling, confirm in a dress rehearsal and scale back down in an orderly way after the event. That turns a risky campaign day into a plannable service. This is exactly the core of our performance maintenance: we prepare Shopware and WordPress shops proactively for their revenue peaks. Flanked by continuous monitoring and an SLA maintenance contract with clear response times, the peak is no longer the moment of truth, but a rehearsed procedure.
- Expected peak estimated from last year, campaign and growth; buffer set.
- Realistic scenario defined -- user mix, ramp, write load, third-party systems.
- Breaking point determined and the first-exhausted resource named.
- Caching exhausted, autoscaling thresholds set from test data.
- Dress rehearsal at target scale passed, rollback and response paths ready.
- Scaled back down after the peak, report and baseline secured for the next campaign.
Sources and Studies