Skip to content

Prepare for peak traffic

Expecting a traffic peak, such as Black Friday, a sale, a TV appearance or a newsletter going out?

This article describes what to check and change beforehand, so the peak doesn't turn into slow pages, failed checkouts or undelivered mail.

Work in this order

  1. Read your baseline in 'Metrics', so you change numbers based on measurements instead of guesses.
  2. Size 'Max Children' for the number of concurrent requests you expect.
  3. Check the CPU and memory limits on the site, its crons and its daemons.
  4. Move bulk and transactional mail to an email service, because outgoing mail on the cluster is limited to 1,000 messages per day.

Start step 4 at least a week before the peak. Domain verification and reputation warm-up aren't instant.

1. Read your baseline in Metrics

Core records CPU and memory usage per FPM pool, Passenger app, cron and daemon, plus CPU usage and total connections per database user.

Look at what the site uses on a normal day first. The peak is a multiple of that number, not a new unknown.

The time range selector at the top of every 'Metrics' page switches between 'Half hour', 'Day' and 'Month'. Use 'Month' to find the normal level and previous peaks, and 'Half hour' while the peak is happening.

Per project

  1. Navigate to 'Projects'.
  2. Select the project.
  3. Under 'Insights', select 'Metrics'.

Shows the FPM pool, Passenger app, crons, daemons and database users belonging to this project.

Per FPM pool

  1. Navigate to 'Advanced' > 'FPM Pools'.
  2. Select the FPM pool.
  3. Select 'Metrics'.

Per node

  1. Navigate to 'Servers' > 'Nodes'.
  2. Select the node.
  3. Under 'Advanced', select 'Metrics'.

Shows every site, cron, daemon and database user on that server, each as its own line.

Check this one before raising any limit. If the node is already close to its CPU or memory capacity on a normal day, raising a limit on one site only moves the problem — you need a bigger node or an extra node.

2. Size Max Children for the peak

'Max Children' on the FPM pool is the maximum number of PHP requests the site can handle at the same time.

When all workers are busy, further requests wait in a queue. Visitors see a page that takes seconds to start loading, and if the queue grows long enough, a 502 or 504 error page.

The formula

Max Children = page views per second × seconds per page × 3

The × 3 leaves room for bursts.

  • Page views per second at the peak — take the busiest hour you expect, divide its page views by 3600.
  • Seconds per page — only the time PHP spends generating the page, not the full load time in the browser. Google Analytics, Tideways or your own testing give you this.

Worked example. 180,000 page views in the busiest hour = 50 per second. An average page takes 0.2 seconds of PHP time. 50 × 0.2 × 3 = 30 workers.

Two things change the number a lot:

  • Page caching. With a full-page cache (through Redis or a caching plugin), a cached page never starts a PHP worker. Only count the page views that actually reach PHP: typically the cart, the checkout, logged-in visitors, and search and filter URLs.
  • Slow pages. A page taking 1 second instead of 0.2 needs five times as many workers for the same traffic. Making pages faster is almost always cheaper than adding workers.

Check it fits in memory

Every worker uses memory, busy or idle. A WordPress or WooCommerce worker typically uses 64 to 128 MB. For your own figure, look at the FPM pool's 'Memory Usage' graph and divide by the number of workers that were running.

30 workers at 128 MB each is roughly 3.8 GB the node must have free.

If the node does not have it, the node runs out of memory and the system starts killing processes — which takes the site down harder than a queue ever would. Lower 'Max Children', make the site use less memory per request, or move to a larger node.

3. Check CPU and memory limits

'CPU Limit (cores)' and 'Memory Limit (MB)' are not set by default, so most sites have no limit. But they may have been set earlier — by you, or by Cyberfusion while solving an earlier problem on the node. A limit that was comfortable at normal traffic is the first thing to break at peak traffic.

Check:

  • The FPM pool — 'CPU Limit (cores)' and 'Memory Limit (MB)'. When the pool hits the memory limit, PHP processes are killed and visitors see errors.
  • Every cron — 'Memory Limit (MiB)', 'CPU Limit (cores)' and 'Timeout (s)'. A product feed or stock sync that normally finishes in two minutes can take much longer when the database is busy with real visitors, and then gets killed by the timeout.
  • Every daemon — 'Memory Limit (MiB)' and 'CPU Limit (cores)'. A queue worker killed for exceeding its memory limit stops processing jobs, and orders sit in the queue unprocessed.

Also check PHP's own memory_limit, a separate setting that caps a single PHP script rather than the pool. See Change PHP settings.

Raising a limit is only safe when the node has capacity, so read the node's 'Metrics' page first.

4. Move bulk mail to a transactional email service

Outgoing mail through the cluster is limited to 1,000 messages per day. A peak passes that easily: order confirmations, shipping notifications, password resets and a newsletter can add up to thousands of messages in a few hours. Past the limit, further messages are not delivered.

A transactional email service also handles deliverability — SPF, DKIM, DMARC, reputation and bounce handling — so mail sent this way is less likely to land in a spam folder.

Two EU-based options (not affiliated):

Steps:

  1. Create an account and verify your domain by adding the DNS records the provider gives you.
  2. Set the SMTP credentials in your application. In WordPress, through an SMTP plugin; in Magento and Shopware, under the mail settings.
  3. Send a test message and confirm it arrives.

Do this at least a week before the peak. A provider may also limit volume on a brand-new account.

During the peak

  • The FPM pool's 'Current Requests' page shows the requests being handled right now. Constantly full means you are out of workers.
  • The FPM pool's 'Metrics' page on 'Half hour' shows CPU and memory usage as it happens.
  • Set 'Log Slow Requests Threshold' on the FPM pool before the peak. Afterwards, ask Cyberfusion for the slow log to see which requests were slow. See Slow request logging.
  • Bot traffic competes with real visitors for the same workers. The limits in that article keep a bot wave from eating the capacity you reserved for customers.