Surviving Peak Sale Days: Bare-Metal Tuning for WooCommerce and High-Traffic Stores

Peak sale days do not stress-test your store’s design. They stress-test your database, your PHP worker pool, and your cache invalidation logic — all at once, all at 3 a.m. This is the pre-event checklist we run for ecommerce operators who host on their own hardware, ordered by when each task should happen before the event.

Week 4 Out: Establish a Baseline

You cannot tune what you have not measured. Before touching a single config value, capture two weeks of normal traffic and record four numbers. If you are still deciding whether your hardware is up to the job at all, it is worth reading up on high-traffic dedicated server hosting and what a store of your size actually needs, because no amount of tuning rescues an undersized node.

Peak concurrent PHP-FPM requests and worker saturation.
p95 and p99 TTFB, split by page type: product, category, cart, checkout.
Database query time for cart and checkout queries specifically.
Bytes served and peak egress per hour.

These four numbers tell you which layer breaks first. In most stores it is checkout — because checkout is the one page you cannot cache, and it is also the page where a slow response costs real revenue.

Week 3 Out: Harden the Database First

Ecommerce traffic is write-heavy in exactly the wrong places. Orders, sessions, cart updates, and inventory counters all hit the database uncached. Tune in this order:

Move the database to NVMe. Nothing else compensates for a shared or SATA-backed data directory under write bursts.
Set the InnoDB buffer pool to roughly 60–70% of available RAM, leaving room for the OS page cache and the web tier.
Switch session storage off MySQL. Redis or a filesystem-backed handler removes the single hottest write path.
Isolate transactional tables from analytics or reporting schemas if your catalogue is large.

Week 3 Out: Size the PHP Worker Pool

Oversized worker pools are the classic peak-day self-inflicted wound. Each PHP-FPM worker holds real memory, and too many cause context-switching thrash and database connection exhaustion rather than more throughput.

Resource	Practical starting point
pm.max_children	Available RAM ÷ average worker RSS, minus DB headroom
DB max_connections	max_children × 1.5
Redis	Dedicated instance, maxmemory-policy allkeys-lru
Opcache	256–512 MB, validate_timestamps off in production

Then load test with realistic traffic. Tools that only hit cached pages will flatter you. Test the cart and checkout flows with concurrent virtual users and watch where latency appears first.

Week 2 Out: Cache the Right Things

Full-page cache in front of product and category pages to absorb crawler storms and browse traffic.
Object cache (Redis) for queries, transients, and options.
CDN for static assets — keep images, CSS, and JS off your origin entirely. Peak days are bandwidth days as much as CPU days.
Exclude cart, checkout, and account pages from page cache, and verify the exclusion actually works with cookies present.

Week 1: Rehearse Failure

The most valuable pre-event test is not a load test; it is a failure rehearsal. Kill one PHP worker mid-request, restart MySQL, unplug a NIC, and confirm the store degrades rather than dies. A sudden CPU spike you have already seen is a non-event on the day.

Failure injected	Expected graceful behaviour
MySQL restart	Connection retry, brief 503, no data loss
One web node down	Load balancer removes it, others absorb
Cache cold	Origin survives stampede via request coalescing
Disk near full	Alerts fire before writes fail

Monitoring on the Day

Tuning without live monitoring means you find out about a problem from customers instead of dashboards. On the day itself, watch a short list of high-signal metrics and set alerts before traffic arrives.

Metric	Alert threshold	Meaning
DB connections used	> 80% of max	Worker pool or query time climbing
p99 checkout TTFB	> 1.5 s	Revenue-affecting latency
PHP-FPM queue length	rising for 60 s	Workers exhausted
Disk write latency	> 10 ms	Storage is the bottleneck
Cache hit ratio	falling sharply	Invalidation or cold cache

The Hardware Side

Software tuning has a ceiling set by the metal underneath. A high-traffic store wants fast NVMe for the database, enough RAM to hold the buffer pool plus the worker pool plus Redis, and CPU headroom for the checkout spike that no cache can absorb. Shared virtualisation and noisy neighbours are where peak-day plans fail, which is why large stores move to bare metal before their biggest events. Our dedicated web hosting server guide covers the specs that matter for this workload.

The order matters: measure, harden the database, right-size the workers, cache aggressively, then rehearse failure. Do it in that sequence and peak day becomes a busy day rather than an outage.