Bad traffic stopped before the server
Rules to challenge unverified visitors and rate-limit the old domain, block crawler patterns on uncacheable pages, and remove obsolete DNS records.
Call Us Now 0333 444 0283
- Call Us Now 0333 444 0283
- Discover
Established 2003
Websites, software and connected business systems
Discuss your project →
Case study · Hosting, Cloudflare & WooCommerce performance
Bringing a WooCommerce Server Back from 100% CPU
Tracing a server overload from the Cloudflare edge to the server and into the WooCommerce code, then fixing every layer.
A cloud server hosting several busy WooCommerce shops and business websites began hitting 90 to 100% CPU without warning. Pages slowed, then timed out, and client websites went offline while customers were trying to buy.
There was no single obvious cause. Traffic floods, crawlers, caching and the shops themselves all played a part. Solving it meant understanding the whole stack, not just one layer of it.
Discuss a performance problem- Environment
- Managed cloud server behind Cloudflare, hosting several WordPress and WooCommerce sites
- Symptom
- CPU at 90–100%, timeouts and client sites offline
- Requirement
- Restore service fast, then find and fix the real causes
- Approach
- Evidence from every layer: edge, server and application
The situation
Every site on the server was at risk
When a shared server runs out of capacity, every website on it suffers. The phones were ringing, and the first job was to get client sites working again without guessing at the cause.
- Was the server being flooded with traffic, or was the problem inside it?
- Was Cloudflare stopping bad traffic, or was some of it getting through?
- Which website, and which pages, were actually using the server’s time?
- Why had a server that had run smoothly for months suddenly started struggling?
The investigation
Following the evidence through every layer
Each finding narrowed down the next question. Several separate problems had combined to overwhelm the server.
-
01
A forgotten domain
The shop’s old domain, kept only to redirect visitors, was receiving around 245,000 requests a day from automated crawlers. Every request was redirected to the live shop’s homepage, quietly adding load the main site’s figures didn’t show.
-
02
Proof the problem was inside
Cloudflare’s analytics showed fewer than 30 requests a minute reaching the server during a full CPU spike. That was far too little traffic to explain the load, so the cause had to be inside the server.
-
03
Crawlers on pages that can’t be cached
Slow-request logging showed crawlers working through endless combinations of WooCommerce product filters and add-to-basket links. Each of those pages has to be built from scratch, so every visit cost real server time.
-
04
Heavy pages and a missing cache
A large mega menu and a slow theme feature were rebuilt on every page. The database cache had been switched off after it ran out of memory, so every page went back to the database again and again.
-
05
Server settings under strain
The server’s code cache was full, duplicate optimisation layers were doing the same work twice, and background tasks were running on visitors’ page loads.
What we changed
Fixing every layer, from the edge to the code
No single change would have solved this. The fix was a set of targeted improvements at each level of the stack.
Lighter pages for every visitor
The mega menu is now cached, the slow theme feature was fixed, and crawlers are steered away from filter and basket links.
Back on, and kept under control
The cache was re-enabled with a sensible memory limit, so it can no longer grow until it crashes, and moved to a faster connection.
Tuned for the real workload
A larger code cache, fair limits per site, and duplicate optimisation layers removed where caching was already handled elsewhere.
Off the visitor’s page load
Scheduled WooCommerce tasks now run on a proper server timer, instead of slowing down whoever happens to visit.
Images moved off the server
The largest shop’s image library was moved to separate cloud storage, freeing space and memory on the server.
The result
A calm, stable server and every site back online
Server load dropped from peaks of 40 to 65 down to a steady 2.5 to 5, with CPU running at 15 to 40% instead of being pinned at 100%. Slow requests went from about 138 an hour to almost none.
Pages now build about twice as fast, and the busiest shop makes a tenth of the database queries it did before. Every client website on the server came back online and has stayed stable since.
100% → 15–40%
Server CPU
380 → 35
Database queries per uncached page
138 → ~0
Slow requests per hour
2× faster
Page build time
Why it matters
A bigger server would not have fixed this
When a server runs out of capacity, the easy answer is to buy a bigger one. Here, that would only have given the crawlers and bots more room to consume, with the monthly bill rising and the real causes still hidden.
Finding out what was actually using the server meant the existing one was more than enough. Problems like this also tend to bounce between suppliers: the host blames the website and the developer blames the host. Because we work across Cloudflare, the server and the WooCommerce code, we followed the evidence wherever it led and fixed each layer directly.
Is your server or website struggling under load?
Tell us what is happening. We will look at the evidence across Cloudflare, the server and the website, and explain the sensible next step.
Call 0333 444 0283 or contact Digital Flair.