Hosting under Last: What your shop really needs in November

Your online store won't crash on Black Friday because the server is too small. It will crash because a single component will fail first—and that's almost never the one you'd expect. This article outlines the four bottlenecks in the order they typically occur and what question you should ask your hosting provider before things get serious.

Friday's tech check focused on the fourteen points you can check yourself. One of them gets uncomfortably specific: charging time under load. Because this is where the checklist ends and the infrastructure begins.

First, a word of reassurance: you most likely don't need a larger server. You need to know where your current one will first reach its limit. That's a different question—and it's considerably cheaper to answer.

Why “it’s going well” no longer applies in November

Normal operation is a poor guide. With twenty simultaneous visitors, your shop is idling: every request immediately gets a free process, the database responds from memory, and caches are warm. None of this applies with four hundred.

Under load, a system doesn't behave linearly, but in stages. Up to a certain point, almost nothing happens—the response time increases from 300 to 400 milliseconds, barely noticeable. Then a resource becomes scarce, requests begin to wait, and the response time jumps from 400 milliseconds to eight seconds. Not gradually. Abruptly.

The relevance of this becomes clear when looking at the sales distribution: Online and mail-order retail sales in December 2025 were 5,2 percent higher in real terms than in the same month of the previous year, and even 10,1 percent higher for the year as a whole – as can be seen in the Federal Statistical Office's analysis of retail sales . So the customers are coming. The only question is whether your shop can serve them.

The four bottlenecks — in the order they tip over

When we put shops under load, almost always one of these four resources gives out first. The order is remarkably consistent.

1. PHP workers: the most common cause, the least understood

Your web server maintains a fixed number of PHP processes—often between 5 and 30. Each process can handle exactly one request at a time. If all processes are occupied, new requests wait in a queue. The visitor sees: nothing. Just a page loading.

The tricky part is that the number of workers isn't the problem. The problem is the time each worker remains occupied. With 20 workers and 200 milliseconds per request, you can theoretically achieve 100 requests per second. With 20 workers and two seconds per request, you can achieve ten. Same hardware, one-tenth of the capacity.

Therefore, "more workers" is rarely the solution—they all need memory. The solution is almost always: process requests faster.

Here's how to find the value: Check your PHP-FPM pool configuration for the maximum number of concurrent child processes. Multiply this by the memory limit per process. If the result exceeds the available memory, your server is theoretically oversubscribed at full load—it will only function as long as not all processes reach their limit simultaneously. In December, they do.

2. Database: the bottleneck behind the bottleneck

If a worker remains occupied for two seconds, it is usually waiting for the database. Typical causes include a category view with multiple filters, a search query without a matching index, or a report in the backend that someone happens to access on Black Friday.

Queries that appear harmless in the test system are particularly problematic. A category query across 200 products runs in 30 milliseconds. The same query across 8.000 products with three active filters can take 1,5 seconds—and it's only executed when a customer selects that exact filter combination. Someone selects it in December.

Almost every shop system includes a log for slow queries. Activate it for a week, with a threshold of one second. What appears in the list after that is your task list—sorted by urgency, entirely without consultation.

3. Cache: only helps as long as it's warm.

E-news for ambitious developers - read up to speed Load testing in practice: How to find the limit before the customer does.

A cache doesn't speed up anything it doesn't recognize. That's precisely the trap during the Christmas season: your campaigns drive visitors to pages that hardly anyone has visited before—category combinations, filter pages, search results. Each of these visits is a dead end and generates exactly the expensive database query from point 2.

Calculate how many combinations your category pages generate: With five filters, each with four options, that's over a thousand possible pages. No cache can hold them all. Therefore, it makes more sense to pre-load the ten most frequent combinations than to rely on a high cache rate.

Second pitfall: A cache that is completely emptied with every inventory change. In December, inventory levels change every minute. Check whether your system is selectively invalidating individual entries or using a sledgehammer approach.

4. Network and TTFB: the rest

Only in fourth place does what most people think of first come into play: bandwidth and server location. For a German shop with German customers, this is rarely the bottleneck—provided the server is located in Europe and the images are delivered in reasonable formats.

The Time to First Byte becomes relevant: How long does it take for the server to even start responding? If this value increases significantly under load, the cause always lies in points 1 to 3 — never in the network itself.

Which hosting form do you really need?

The honest answer is: It depends less on revenue than on what happens when things get tight. This overview helps put it into perspective.

The most common misconception lies in the last line: Autoscaling doubles the number of web servers when needed, but the database remains the same. If your bottleneck is in point 2, Autoscaling actually makes things worse—more processes access the same overloaded database.

Availability is a choice, not a coincidence.

It's worth looking beyond the confines of e-commerce here. The German Federal Office for Information Security (BSI) differentiates availability into clearly defined classes—from "normal" to "highly available"—and emphasizes that higher classes are not achieved through better hardware, but rather through redundancy, processes, and practiced restarts. The fundamentals are described in the BSI's introduction to high availability.

For an online shop, this translates to: Don't ask "how fast is the server?" but rather "what happens if it fails?" How long does it take for someone to notice? How long until it's back online? And has this restart procedure ever been tested?

For those who want to delve deeper: The IT baseline protection module APP.3.1 for web applications and web services describes the requirements for operation and security — including the often overlooked points of logging and load limiting.

Three myths that will become expensive in November

Before we get to measuring, here are three assumptions that we keep encountering in conversations — and that cost money during peak season.

“We have plenty of RAM.”

RAM is rarely the bottleneck, but rather the consequence of a decision: it limits how many PHP processes can run simultaneously. If each process reserves 256 MB and the server has 8 GB, the limit is reached at 30 processes—regardless of CPU speed. Increasing the number of processes without reducing the memory allocation per process introduces swapping. And a swapping server is slower than a fully utilized one.

"The shop was also fast last year."

A shop slows down over the year without anyone doing anything wrong. The catalog grows, log tables fill up, extensions are added, each with its own queries. A system that ran at 300 milliseconds in January often runs at 600 milliseconds in August—with identical hardware and traffic. This is normal. It only becomes a problem if no one measures it.

“In case of emergency, we can increase our capacity at short notice.”

This assumption holds true for cloud providers but often doesn't for managed hosting. Upgrading your hosting package can mean a migration, with a notice period and maintenance window. That's precisely why this question is further down the list: you want the answer in August, not on November 25th.

The underestimated factor: your own backend

One point that's never mentioned in any hosting brochure: your team is using the same server. A product export, a report on all orders for the month, a bulk price update—these kinds of processes occupy PHP processes and database connections that are then unavailable for customers.

For peak weeks, establish a simple rule: no exports, no bulk changes, and no reporting between 17 PM and 22 PM. It costs nothing and takes effect immediately.

What you need to measure — and what you can measure

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

A load test sounds like a complex tool, but in its basic form it is simple: You send an increasing number of simultaneous requests to typical pages and observe when the response time starts to tip over.

The selection of pages is crucial. Don't test the homepage—it's usually well cached and therefore not very informative. Test a category page with active filters, a search results page, and the shopping cart. These are the pages that generate the most traffic in December.

For pure user experience, there are also fixed thresholds that Google has defined in its Core Web Vitals documentation : 2,5 seconds for the largest visible content, 200 milliseconds for response to input, and 0,1 for layout stability. These values ​​apply to real users in the field—including visitors who arrive at 20 p.m. on Black Friday. We explained what each of these three metrics means in detail in our article on INP, LCP, and CLS.

Five questions for your hosting provider

You don't need to be a system administrator to ask the right questions. These five are enough to assess whether your hosting is suitable for peak usage — and the answers often reveal more about the provider than any service description.

First: How many PHP processes are available to my shop simultaneously, and how much memory does each have? Second: Where is the database running—on the same server or separately, and how much memory does it have? Third: Can I increase the capacity for November at short notice, and how long would that take? Fourth: How will I be notified of an outage—and how quickly? Fifth: When was a restart from a backup last tested?

If you don't get an answer to question five, you already have your most important information.

What you can do this week

Three things that don't require a contract or a budget. First: Enable logging for slow database queries, with a threshold of one second. In a week, you'll have a reliable list. Second: Access a filtered category page and measure the time until the first byte is loaded—once in the morning and once in the evening. If the time differs significantly, you have a load problem, not a loading time problem. Third: Ask your hosting provider the five questions. Send them by email so you have the answers in writing.

Conclusion: Measure first, then buy

The most expensive decision before the peak season is a larger server, which doesn't solve the underlying problem. The cheapest is a week with slow query logging enabled.

Both answer the same question—only one costs money and the other requires attention. And in the vast majority of cases we've seen, the solution wasn't more hardware, but three or four queries that no one had ever looked at.

Where will your shop give in first?

Have you ever performed a load test — and what were the results? I'm particularly interested to know if the sequence described in this article was confirmed for you, or if something completely different gave way first.

And the question that will probably elicit the most interesting answers: What answer did your hosting provider give you to question five? Write it in the comments—anonymously, of course. Everyone learns more from such experience reports than from any service description.

If you want to know how your shop is technically performing before it experiences a load: Our free technical and visibility check analyzes every website without registration. And if you prefer to conduct a load test with assistance, you can reach 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: The pre-season product data feed — Google Shopping, marketplaces , and common pitfalls.