A small WooCommerce store with page caching usually fits in 5 PHP workers, a store taking dozens of orders a day needs about 10, and a sale with hundreds of people in checkout at once needs 16 or more. The exact number follows from one formula: workers ≈ PHP requests per second × average PHP response time in seconds, plus headroom for bursts.
What a PHP worker is
A PHP worker is one process executing WordPress and WooCommerce code for one request at a time. The number of PHP workers is the number of requests a store can serve simultaneously without queueing. When all are busy, the next request waits or fails — on Aderlo Cloud the server returns HTTP 508 instead of silently slowing everything down.
Not every page view uses a worker. A product or category page served from the page cache (LSCache) never starts PHP. Workers are needed for what cannot be cached: cart, checkout, customer account, search, the admin, AJAX calls and cron jobs.
How to calculate the number you need
The average number of busy workers is PHP requests per second multiplied by their average duration (Little’s law from queueing theory). Add 50–100% on top for bursts, because shoppers do not arrive in an even stream.
workers ≈ (PHP requests per second) × (average PHP response time in s) × 1.5–2
| Situation | Peak PHP requests / s | Average PHP time | Busy workers (average) | With headroom |
|---|---|---|---|---|
| Small store, ordinary day | 4 | 0.5 s | 2 | 3–4 |
| Medium store, email campaign | 10 | 0.5 s | 5 | 8–10 |
| Sale, hundreds of people in checkout | 20 | 0.6 s | 12 | 18–24 |
Response time matters as much as traffic. A store whose cart takes 1.2 s instead of 0.4 s needs three times the workers for the same traffic — which is why speeding up slow requests often beats a bigger plan.
Where to get the numbers
PHP requests per second
Count uncached requests in the server log during the worst minute of your last peak (
X-LiteSpeed-Cache: miss, or no such header) and divide by 60.Average PHP response time
Measure time to first byte for cart, checkout and search with the browser cache off. The Query Monitor plugin shows what takes longest.
Peak, not average
Use the hour a newsletter went out or a promotion started, not the daily average — the average hides exactly the minutes in which a store loses orders.
One request that is easy to miss: wc-ajax=get_refreshed_fragments. On some themes it fires on every page view and takes a worker even when the page itself came from the cache.
PHP workers on Aderlo Cloud plans
| Plan | PHP workers | CPU and memory | Price (excl. VAT) |
|---|---|---|---|
| Starter Store | 5 | up to 1.5 vCPU, 2 GB RAM | €12 / month |
| Growth Store | 10 | up to 3 vCPU, 4 GB RAM | €29 / month |
| Scale Store | 16 | up to 5 vCPU, 6 GB RAM | €59 / month |
| Dedicated Commerce | 28 | up to 8 vCPU, 10 GB RAM | €149 / month |
Aderlo Cloud plans differ in power, not in the number of sites. Moving to a bigger plan is one click in the panel, and the Scale Store plan includes a capacity review before Black Friday.
See pricing →When more workers will not help
- A slow database. A large autoloaded
wp_options, missing indexes or thousands of expired transients slow every request; more workers just wait for the database in parallel. - No page cache. Without LSCache every product view takes a worker. Turning the cache on often cuts the need several times over.
- A plugin calling an external API on every request. The worker sits idle waiting for someone else’s server.
- WP-Cron triggered by visitors. Move it to a system cron so background jobs stop taking workers from shoppers.
Frequently asked questions
- Are 5 PHP workers enough for a WooCommerce store?
- For a store with page caching and a few PHP requests per second at peak, yes. If the store regularly sends newsletters or runs promotions where many people check out at once, work the number out with the formula and consider 10.
- What happens when a store runs out of PHP workers?
- Further requests queue or fail. On Aderlo Cloud, hitting the limit returns HTTP 508, visible in the logs, rather than an invisible slowdown of the whole store.
- Are PHP workers the same as CPU cores?
- No. A worker is a process handling one request; a core is the compute the workers share. Many workers on too little CPU will still be slow, which is why plans state both.