What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Short answer: A busy WooCommerce site is limited by PHP-FPM child processes, not an abstract “thread” number. There is no universal worker count. Size the pool from measured per-request memory and CPU demand, reserve capacity for the database and web stack, and keep long-running WooCommerce jobs from consuming the workers needed for cart and checkout.
What “PHP threads” means on WooCommerce hosting
Most PHP hosting dashboards use “PHP workers” or “PHP threads” as a customer-friendly label for concurrent PHP-FPM capacity. In practice, the unit you size is usually a PHP-FPM child process in a pool. Each child handles a request while it is busy; additional requests wait when all children are occupied.
The PHP Documentation Group describes FPM (FastCGI Process Manager) as “a primary PHP FastCGI implementation containing some features (mostly) useful for heavy-loaded sites.” FPM supports configurable pools, dynamic, ondemand, or static child spawning, slow logs, and status information. Those controls determine how many requests can run at once, how quickly children are created, and how much memory can be committed.
A larger ceiling does not automatically make checkout faster. More children help only while CPU, memory, database connections, object cache, payment APIs, and other upstream resources have spare capacity. Once one of those resources is saturated, extra workers create contention and longer queues rather than useful concurrency.
#1 Best Overall
Why there is no universal worker number
Two stores with the same order volume can need very different pools. A catalog page that is served from cache may use little PHP time, while a checkout request can perform session, inventory, tax, shipping, discount, payment, and database work. Extensions also change the memory and execution time of each request.
The cited PHP and WooCommerce documentation does not publish a formula that converts traffic into a guaranteed worker count or requests-per-second result. Treat any exact number as an infrastructure-specific result, not a recommended default.
Recommended Free Tools
Use a capacity equation, not a guess
Start by measuring the memory footprint of one representative PHP-FPM child while it handles real WooCommerce traffic. Then reserve memory and CPU for the database, web server, operating system, object cache, monitoring, and safety margin. A practical upper bound is:
worker ceiling = memory available for PHP ÷ measured peak memory per child
Use the lower limit imposed by CPU and database capacity if it is smaller. “Memory available for PHP” must exclude the resources those other services require; dividing total server RAM by a process-size estimate is unsafe. Measure more than one request class, because checkout, account pages, REST requests, and administration can have very different footprints.
Rank #2
Metrics that reveal the real limit
- PHP-FPM active and idle children: sustained zero idle children indicates saturation; a permanently large idle pool may indicate waste.
- Max-children reach events: repeated events show that the configured ceiling is being hit, but do not prove that adding children is safe.
- Request latency: track p95 and p99 separately for cart, checkout, account, REST, administration, and uncached front-end requests.
- Slow-log traces: identify PHP code, database calls, or external requests that hold a child for an excessive time.
- Memory pressure and swapping: swapping can make every request slower and can turn a modest worker increase into an outage.
- Database CPU, locks, and connection usage: a PHP pool can be idle while requests wait on the database, or it can overwhelm the database by opening too many concurrent queries.
- 5xx responses and upstream timeouts: correlate errors with worker saturation, memory exhaustion, database failures, and payment or shipping API latency.
Choose the PHP-FPM process model deliberately
Static children
A static pool keeps a configured number of children available. It provides predictable capacity and avoids process-creation delays, but all of the configured memory may be committed even during quiet periods. It is appropriate when traffic is steady and the host has measured headroom.
Dynamic children
A dynamic pool maintains a minimum number of idle children and grows toward a maximum as demand rises, then retires excess idle children. It is a useful general-purpose mode when traffic varies, provided the maximum is constrained by measured memory and database capacity.
Ondemand children
An ondemand pool creates children when requests arrive and removes them after an idle period. It can reduce idle memory use on a low-traffic or isolated pool, but bursts may pay process-start overhead. Do not use it as a substitute for capacity planning on a checkout path that must absorb sharp peaks.
Regardless of mode, the maximum child setting is a safety boundary, not a performance target. Raising it without observing CPU, memory, database locks, and latency can make a failure happen faster.
Protect customer traffic from background work
WooCommerce sites handle two distinct workloads: interactive requests such as cart and checkout, and asynchronous work such as imports, email, webhooks, subscription renewals, and scheduled extension tasks. Mixing them in one pool allows a queue burst to consume every child needed by shoppers.
How WP-Cron couples jobs to visitors
WP-Cron checks for scheduled work when the site receives a request. On a low-traffic site, jobs can run late because there are few requests to trigger the check. On a busy site, frequent checks add work during the same periods when customers are active. A real server cron can trigger WP-Cron independently of visitors, separating scheduling from page traffic.
Action Scheduler’s conservative defaults
Action Scheduler is the queue used by WooCommerce and many extensions. Its documented default behavior is deliberately cautious:
| Setting or behavior | Documented default or qualification |
|---|---|
| Actions claimed per batch | 25 actions |
| Maximum request run time | Up to 30 seconds by default |
| Concurrent batches | One batch at a time by default |
| Stopping condition | Stops when memory or time limits are reached and continues in later requests |
Those limits reduce the chance that one queue request monopolizes the web pool. They are not throughput guarantees. A short, lightweight action may process quickly; an action that calls a slow API or performs heavy database work may consume most of the request window.
When a separate queue runner is justified
For a busy store, run due actions from a real server cron and, where available, WP-CLI. This gives operators explicit timing and allows queue work to run in a dedicated PHP-FPM pool, process group, or host. Keep checkout, account, REST, and payment-callback capacity on a pool with protected workers.
The Action Scheduler performance documentation warns that increasing concurrent loopback batches can substantially increase server load. Use higher concurrency only after measuring CPU, memory, database connections, and downstream API limits. WP-CLI is identified as a better method for higher throughput when it is available because it avoids relying on many browser-style loopback requests.
Rank #4
What documented Action Scheduler scale does—and does not—mean
Action Scheduler’s project documentation says: “Every month, Action Scheduler processes millions of payments for Subscriptions, webhooks for WooCommerce, as well as emails and other events for a range of other plugins.” The same documentation reports live sites processing queues in excess of 50,000 jobs and resource-intensive workloads at over 10,000 actions per hour in 10 concurrent queues.
These are reported capabilities of the project, not a promise that every WooCommerce installation will reach those rates. Your result depends on action complexity, PHP memory, database schema and indexes, host CPU, network calls, and the behavior of the extensions creating the jobs.
A measurement-first tuning sequence
1. Establish the bottleneck
Capture PHP-FPM active and idle counts, max-children reach events, slow-log traces, request latency, memory pressure, database CPU and lock activity, and Action Scheduler pending and failed counts. Record normal traffic and a sale-like burst if your business has predictable peaks.
Free tools Windows power users keep installed
One-click scans. No signup required.
2. Protect interactive capacity
Identify the minimum capacity required for cart, checkout, account, REST, administration, and payment callbacks. Reserve that capacity instead of allowing scheduled work to consume every child. If a job regularly runs for many seconds, treat it as a queue workload rather than an ordinary page request.
3. Start with conservative queue limits
Keep the documented 25-action batch and 30-second request defaults until you know the memory and duration of your actions. Increase batch size only when actions are short and memory use is understood. Increase concurrency only when the database, CPU, memory, and external services have measured headroom; careless loopback concurrency can take down a site.
4. Move high-volume work to an explicit runner
Use server cron to invoke the queue independently of visitors and use WP-CLI where available. Assign that runner to a separate pool or host when background work competes with checkout, or when retries and long actions create unpredictable load.
5. Change one limit at a time
After each change, compare p95 and p99 checkout latency, PHP-FPM saturation, database load, queue age, failed actions, and 5xx rates. Test both ordinary traffic and burst conditions. If latency worsens while the queue drains faster, the change may have traded customer experience for background throughput.
Architecture choices for a busy store
| Design | Isolation | Throughput | Latency risk | Failure containment | Operational cost |
|---|---|---|---|---|---|
| One shared PHP-FPM pool | None; jobs and shoppers compete for the same children | Simple, but limited by interactive peaks | Highest risk during queue bursts | A retry storm can consume web capacity | Lowest complexity |
| Separate web and queue pools | Protects checkout workers from scheduled jobs | Each pool can be tuned to its workload | Lower customer-impact risk if web capacity is reserved | Queue failures are less likely to block pages | Requires pool configuration and monitoring |
| Dedicated queue worker host | Strongest isolation from the web server | Can scale queue execution independently | Best protection when queue load is large or spiky | Web failures and queue failures are largely separated | Highest cost and operational complexity |
Evaluate these designs on six axes: whether background jobs can starve checkout workers, how quickly the pending queue drains, p95 and p99 cart or checkout latency during bursts, whether retries consume web capacity, whether operators have WP-CLI, cron, slow logs, and status metrics, and the added cost of another pool, host, or managed service.
Troubleshooting common symptoms
All workers are busy and checkout is slow
Confirm whether requests are CPU-bound, waiting on the database, or blocked on an external API by checking slow logs and database metrics. If scheduled actions coincide with the saturation, move them to a protected queue pool before raising the web pool ceiling. Add children only when CPU, memory, database connections, and downstream services remain below safe limits.
Workers are idle but requests still wait
Idle PHP-FPM children point away from a worker-count problem. Investigate database locks, connection limits, web-server queues, object-cache misses, network calls, or payment and shipping providers. Increasing PHP children cannot remove a bottleneck outside PHP.
The server starts swapping after a worker increase
Reduce the pool ceiling and inspect peak child memory, not just an average. Keep memory reserved for the database, operating system, web server, cache, and monitoring. Swapping is evidence that the new concurrency level is unsafe.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →The Action Scheduler queue keeps growing
Check pending, running, and failed counts, action duration, and the schedule that triggers the runner. A growing queue may reflect insufficient runner time, slow actions, repeated failures, database contention, or an external API limit. Increase concurrency only after identifying which condition applies; otherwise the queue can grow while customer requests degrade.
Quick Recap
Practical operating checklist
- Define separate service objectives for checkout latency and queue age.
- Record PHP-FPM active, idle, and max-children events continuously.
- Measure peak memory per representative WooCommerce request.
- Reserve CPU, memory, and database connections before setting a PHP ceiling.
- Keep Action Scheduler at its documented conservative defaults until measured data supports a change.
- Use server cron and WP-CLI for high-volume queue execution when available.
- Give long-running or retry-prone jobs a separate pool or host.
- Compare p95 and p99 checkout latency, queue age, failed actions, database load, and 5xx responses after every adjustment.
- Document the setting, observation window, traffic conditions, and rollback value for each change.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
