The problems are already there
A busy weekend almost never breaks a shop in a way nobody has seen before. It finds the slow query, the page that isn't cached, the cron job that locks a table, the payment callback that times out. All of those exist at normal traffic too. Nobody notices them at normal traffic. So the job is to find them while there's still time to fix them, and then to stop touching anything.
Stop changing things
Pick a freeze period. We usually go from about ten days before the campaign until the Tuesday after Cyber Monday. During the freeze:
- No updates to the core, modules or extensions, except security fixes, and those one at a time after someone has read them.
- No theme changes, no new tracking scripts, no new marketplace connectors.
- Prices and content change through the back office as normal. Nobody edits the database by hand.
A freeze only helps if the last planned release goes out before it starts, early enough to watch the shop for a full working week afterwards.
Work out how much traffic is coming
Start from last year's figures. The number that matters is uncached requests per second reaching the server. Page views don't tell you much, because most of them should be served from cache.
- Find last year's busiest hour in the access logs.
- Add the growth you expect and the effect of the campaign.
- Load-test a copy of the shop with the same amount of data as production. Use a realistic mix: category pages, search, product pages, add to cart, the start of checkout.
Then watch what gives first. PHP-FPM running out of workers, the database running out of connections, or CPU steal on a shared host. Each one has a different fix.
; PHP-FPM pool: size it from measured memory per worker, not from the defaults
pm = static
pm.max_children = 24 ; (RAM available to PHP) / (average RSS per worker)
pm.max_requests = 1000 ; recycle workers to contain slow leaks
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/shop-slow.log
Caching
Magento. Production mode, full-page cache served by Varnish, and indexers on "Update by Schedule", so saving a product in the middle of a sale doesn't set off a full reindex:
bin/magento deploy:mode:set production
bin/magento indexer:set-mode schedule
bin/magento indexer:status
Make sure cron runs every minute and its queue is empty before the campaign starts.
PrestaShop. Debug mode off, Smarty set to never recompile templates, caching on, and CCC (combine, compress, cache) tried on the copy first, because some modules don't survive it. Uninstall modules that are disabled but still installed.
On both platforms, measure the hit rate under load. A stray cookie or query parameter can make the cache skip almost every request, and you won't see it until the load test.
Everything the checkout depends on
The checkout is as fast as the slowest thing it calls. Make a list and check each one:
| Depends on | What to check |
|---|---|
| Payment provider | Subscribed to their status page; webhook endpoint reachable; what happens on a timeout |
| Shipping and label APIs | Rate limits known; a fallback rate set up |
| Order mail | Domain authenticated (SPF, DKIM, DMARC); daily sending limit above the expected order count |
| Search | How fast queries are under load |
| DNS and certificates | Nothing expiring during the campaign |
During the weekend
Alert on what customers would notice, and leave the rest for Monday:
- The start of checkout: status and response time, checked every minute from outside.
- Orders: an alert if the last 30 minutes bring far fewer orders than the same 30 minutes yesterday.
- Payments: the share of failed or abandoned payment callbacks.
- Database: connections in use, and replication lag if there's a replica.
Agree beforehand who can be reached, when, and what each person is allowed to change. The best incident during a peak is one you fix by rolling back something written down in advance.
On Monday
Write the numbers down while they're fresh: peak requests per second at the server, cache hit rate, the slowest pages, the alerts that fired and why. That's the starting point for next year.
