Dynamic PHP Capacity Concurrency planning
PHP Workers Explained: How Many Does Your Website Need?
PHP workers process dynamic requests. When every available worker is busy, new uncached requests can queue even while cached pages remain fast. The useful question is therefore not monthly traffic alone, but how much dynamic PHP work overlaps at the busiest moments.
There is no universal “X visitors = Y PHP workers” rule. A practical planning estimate uses uncached dynamic requests per second, average PHP processing time and burst headroom. Provider metrics also need to stay separate when they measure different controls.
This estimates workload concurrency, not a guaranteed provider worker requirement. Cron jobs, admin-AJAX, checkout actions, imports, API calls and background work can add demand.
Original concurrency estimator
Dynamic PHP Concurrency Estimator
Approximate simultaneous uncached PHP work using request rate and processing time. This is a planning model—not a guarantee of how a provider schedules PHP.
Why caching changes the worker requirement
A full-page cache can serve many anonymous visits without executing the entire WordPress/PHP stack for every page view. Logged-in users, carts, checkouts, searches, forms, API calls and uncached AJAX requests are different: those paths can still require dynamic execution. Two sites with the same monthly visitors can therefore need very different PHP concurrency.
Request rate
Monthly traffic averages hide bursts. A newsletter, crawler, product launch or social spike can create a much higher request rate for several minutes.
Dynamic fraction
A mostly cached blog may send a small fraction of visits to PHP, while membership, ecommerce and logged-in applications can remain highly dynamic.
Processing time
A 150 ms PHP request releases capacity much faster than a 2-second request. Slow database queries and plugins can consume workers longer.
Background work
WP-Cron, scheduled jobs, backups, imports and queue workers can compete with front-end requests for shared server resources.
What the five providers disclose
| Provider | Current public model reviewed | Do not confuse with |
|---|---|---|
| Hostinger | 20 / 40 / 60 PHP workers on current Web Single / Premium / Business | CPU cores, RAM, I/O, total processes |
| Bluehost | No single normalized public shared worker count in the resource source used here | File or database thresholds |
| DreamHost | Shared process monitoring and shared-resource behavior | A fixed provider-wide PHP worker quota |
| SiteGround | CPU-second fair-use limits and RAM per process in reviewed documentation | PHP worker count |
| Namecheap | 20 / 30 / 40 CloudLinux entry processes by tier | PHP workers; entry processes are a different CloudLinux metric |
When more workers will not fix the problem
- The site has one or two very slow database queries.
- A plugin creates a loop or abusive background requests.
- The account is constrained by CPU, RAM or I/O before PHP concurrency.
- Page caching is disabled for content that could safely be cached.
- A bot or attack is generating avoidable dynamic traffic.
- The workload belongs on isolated VPS/cloud resources rather than a larger shared plan.
Use the worker count as one piece of evidence. Repeated queueing plus high dynamic concurrency can support an upgrade decision, but it should be paired with actual resource graphs and application diagnostics.
Claim-level official citations
Use the same source the capacity claim came from.
Resource terminology is not standardized across hosts. Recheck the provider documentation before buying or upgrading because thresholds, plan names, and public disclosures can change.
Research method & evidence discipline
Published limits are compared only when the underlying metric matches.
The page separates hard limits, soft thresholds, planning figures, shared-resource policies, and unavailable public data rather than converting unlike controls into one score.
Page-specific update history
Resource changes are recorded only after substantive verification.
- 01
August 8, 2026 Initial source-backed comparison, original capacity tool, provider caveats, and internal-link cluster published.
- 02
Metric discipline Unlike resource controls stay separate instead of being converted into a fake universal score.
- 03
Future revisions Record the previous value, new value, source, provider context, and verification date when a limit changes.