Optimizing Ubuntu Droplet CPU spikes for a WooCommerce site?

Heya,

Before touching pm.max_children, I’d pin down what’s actually eating the CPU, because for WooCommerce it’s usually not raw capacity. Two things spike stores like this: uncached dynamic PHP requests, and the cron and Action Scheduler batches you already noticed.

On PHP-FPM, max_children isn’t a magic number, it’s a memory budget. Take the RAM left after MySQL and Redis, divide by the average FPM process size (WooCommerce workers tend to sit around 50 to 80MB), and that’s your ceiling. Setting it higher than your RAM can absorb just turns a CPU spike into swapping, which is worse. On a spiky store I run pm = dynamic with a modest max_children, max_spare_servers low so idle workers get reaped, and pm.max_requests around 500 so workers recycle instead of leaking. If you’re guessing, watch how many active workers you actually hit at peak via pm.status_path and size to that plus headroom rather than just cranking it.

The bigger lever is caching the right layer. Redis object cache helps the database, but PHP still runs on every hit. What flattens CPU is FastCGI microcaching in Nginx for anonymous traffic, with cart, checkout, my-account and any logged-in cookie bypassing the cache. Worth checking whether WooCommerce cart fragments (admin-ajax.php) are firing for anonymous visitors, because that one endpoint is a classic CPU sink under traffic. It forces a full PHP bootstrap for people who haven’t even put anything in a cart yet.

For the crons, disable wp-cron with DISABLE_WP_CRON and run it from a real system crontab every few minutes instead of piggybacking on page loads. The inventory jobs are Action Scheduler batches, and if they overlap peak hours they compete directly with real requests, so staggering them or trimming the batch size helps.

On the DigitalOcean monitoring side, the false alarms are because the default alert triggers on a short window. Set the CPU alert to fire on a sustained average, say above 80% for five minutes or more, rather than any single spike. A cron burst that clears in 30 seconds shouldn’t page you, but a genuine capacity problem holds high for minutes. Watching load average against your core count usually tells you more than the raw CPU percentage anyway.

None of this argues against a bigger VPS eventually, but if cart fragments or an overlapping cron are the real cause, a bigger box just takes slightly longer to hit 100%. Fix the cause first, then size to real numbers.

Heya,

One thing worth adding on the cart fragments issue specifically: naming it as a CPU sink is right, but the concrete fix is to dequeue the wc-cart-fragments script itself on pages that don’t need it, rather than just caching around it. That script fires an AJAX call to admin-ajax.php on every page load to refresh the mini-cart, which on a busy storefront can add up to tens of thousands of requests an hour, each one bootstrapping the full WordPress environment. A snippet in functions.php that dequeues wc-cart-fragments on non-cart, non-checkout pages cuts that at the source, plugins like Perfmatters or the dedicated Disable Cart Fragments plugin do the same thing if you’d rather not hand-roll it.

On the upgrade question, worth knowing before you pick a bigger plan: Basic Droplets are shared CPU, meaning DigitalOcean’s hypervisor allocates you more hyper-thread time under load, but how much depends on what your neighbors on the same host are doing. If the spikes you’re seeing during crons are landing on a busy host, a bigger shared Droplet can still be inconsistent for the same reason. A CPU-optimized or general purpose Dedicated CPU plan gives you guaranteed full-time access to your cores instead, which is the more direct fix if the diagnosis work above doesn’t get you all the way there.

Hope that this helps!