Title: 32-Core Server, 126GB RAM... and WooCommerce variable products still take 2.5s+ to generate (TTFB). Hitting the PHP single-thread wall.

I wanted to share an issue we have been investigating recently and see if anyone else has experienced something similar.

We run a WooCommerce store on a dedicated server with significant resources, roughly 32 CPU cores and over 100 GB of RAM. The infrastructure itself should be more than capable of handling a heavy ecommerce workload.

Recently we noticed something unusual when monitoring the server. Large numbers of PHP-FPM workers were staying alive for several minutes at a time, often between 3 and 7 minutes per worker. When inspecting the system with htop, most of the active processes were PHP-FPM workers belonging to the WooCommerce site pool, each consuming roughly 250 to 300 MB of memory.

Interestingly, the CPU was not fully saturated. The issue was more about the number of long lived workers rather than pure CPU exhaustion.

Impact on real users

For cached traffic the site performs well.

However, the problem becomes noticeable for non cached requests, such as:

first time visitors

product configuration requests

cart and checkout interactions

admin actions

certain dynamic WooCommerce endpoints

When the PHP workers are busy with long running background tasks, new uncached requests can sometimes take several seconds longer to respond. This does not affect every request, but it can create occasional slow responses that we would prefer to eliminate.

What we investigated

We started tracing the PHP processes at the server level to understand what they were actually doing.

Using tools such as strace, we observed many workers repeatedly accessing files within:

wp-content/plugins/wp-rocket/

which suggested that cache preloading or related background tasks could be involved.

At the same time we inspected WooCommerce scheduled actions. The Action Scheduler queue contained a very large number of entries, over 25,000 scheduled actions with several hundred marked as failed.

We also noticed that WooCommerce logging had accumulated roughly 2 GB of logs in the wp-content/uploads/wc-logs directory.

Server configuration

For context, the PHP-FPM pool had been configured quite generously:

pm.max_children = 600

This meant the server could potentially spawn hundreds of PHP workers simultaneously.

While the machine has enough RAM to support a large number of workers, this configuration allows many background tasks to run concurrently, which can lead to long lived processes and worker congestion.

What we tried

To stabilise the behaviour we began testing a few changes.

First, we disabled WordPress pseudo-cron and replaced it with a proper system cron job.

In wp-config.php:

define('DISABLE_WP_CRON', true);

Then we scheduled a server cron task to run wp-cron.php every few minutes using the correct PHP version.

We also temporarily disabled WP Rocket cache preloading to see if that reduced the long running worker activity.

Additionally, we cleaned up failed scheduled actions and are considering reducing the PHP-FPM worker limits so that background tasks cannot spawn hundreds of concurrent workers.

What we are trying to understand

At this stage we are trying to determine the primary cause of the behaviour.

Possibilities include:

WooCommerce Action Scheduler executing too many background jobs simultaneously

WP Rocket preload activity generating heavy background load

a large accumulation of scheduled actions over time

or an overly permissive PHP-FPM pool configuration allowing excessive concurrency

The site itself remains usable and generally fast, but the worker behaviour is unusual enough that we want to fully understand it before it becomes a larger issue.

Questions for the community

Has anyone else encountered situations where:

PHP-FPM workers remain active for several minutes on WooCommerce sites

WP Rocket preload tasks generate significant background load

Action Scheduler builds up tens of thousands of scheduled jobs

non cached WooCommerce traffic becomes slower due to worker saturation

If so, what ended up being the root cause and what configuration changes helped stabilise things?

Any insights would be greatly appreciated.