← All articles

August 26, 2026 · Updated August 26, 2026 · Urumi Team

How Many PHP Workers Does WooCommerce Need?

WooCommerce has no universal PHP-worker number. Size workers from measured request duration, peak dynamic concurrency, database headroom, and the checkout journeys that matter.

WooCommerce does not have a universal PHP-worker number. The right capacity depends on how many dynamic requests arrive at once, how long those requests occupy a worker, how much database work they generate, and which checkout-related actions must remain responsive at peak.

A worker is an execution slot for dynamic PHP work. Cached pages may not need one at all; cart, checkout, account, admin, API, and background requests often do. Adding workers can increase throughput when all workers are busy, but it can also overwhelm a database or downstream service if the underlying work is inefficient.

Start with measurements

Measure peak concurrent dynamic requests, median and tail request duration, worker utilization, request queueing, memory usage, database saturation, and error rates. Use distinct measurements for browsing misses, cart changes, checkout, payment callbacks, admin operations, and background jobs.

A useful initial model is concurrency: if a class of requests takes longer, more workers are occupied at the same traffic level. But do not size from an average alone. Tail latency matters because a small number of slow checkouts can tie up capacity precisely when demand rises.

Separate worker pools where possible

Checkout traffic should not be starved by a bulk import, a feed regeneration, or a long-running admin request. Separate or limit background work, keep heavy tasks off known peak periods, and monitor Action Scheduler queues. WooCommerce documents Action Scheduler as a queued system for background tasks; overdue or failed actions should be investigated rather than allowed to accumulate.

Validate the database before increasing workers

More PHP workers create more simultaneous database connections and queries. If the database is already the bottleneck, increasing the worker limit can make response times worse. Inspect slow queries, locking, connection pressure, and order-write performance before raising concurrency.

HPOS can improve how WooCommerce stores and queries order data by using dedicated order tables, but extensions and custom code need compatibility testing before a migration. It is one part of capacity planning, not a replacement for it.

Test a capacity change safely

  1. Capture a baseline with representative browsing and purchase traffic.
  2. Increase capacity by a deliberate increment.
  3. Repeat the same load profile and compare checkout latency, errors, database pressure, and queue depth.
  4. Keep the change only if it improves the customer journey without moving the bottleneck somewhere more dangerous.

Frequently asked questions

Are more PHP workers always better for WooCommerce?

No. They help only when application worker capacity is the constraint and the rest of the stack has headroom. A database-bound or API-bound store can become less stable with excess concurrency.

Do cached pages use PHP workers?

A full-page cache can serve eligible anonymous requests without reaching PHP, while cart, checkout, account, and personalized requests normally require dynamic processing. The exact behavior depends on the cache architecture and store features.

How do I know whether WooCommerce needs more workers?

Look for worker saturation or request queueing that correlates with slower dynamic customer journeys, then confirm that database and dependency capacity can support additional concurrency.

For the broader performance methodology, read Why WooCommerce Slows Down Under Load and How to Scale WooCommerce for High Traffic.

The Urumi approach: More workers on one server are still a vertical-capacity decision. Urumi is built around horizontal scaling for WooCommerce, then operates the database, cache, queues, and application behavior that must keep pace with added capacity.

Built by the people who built WooCommerce core.

We built WooCommerce core at Automattic — the parts that matter in production: performance, payments, reliability. Earlier, engineering at HackerRank (Y Combinator) through its enterprise scale-up. Naman led Payments and WooCommerce releases to 4.5M merchants; Vedanshu led HPOS, Taxes, and Shipping. Run by AI, overseen by the people who built WooCommerce core.

Grow your store's revenue on Urumi.

The AI platform D2C brands use to grow revenue — built by the people who built WooCommerce core.

See the WooCommerce platform  ·  Start your WooCommerce store on Urumi  ·  Talk to the founders

Agent live · 99.99% uptime · shipping today.