PHP Workers in Hosting: Concurrency, Queues and WordPress Capacity
Guides / Hosting limits
Documentation checked: October 5, 2026. This is a documentation-based explanation and HRL troubleshooting checklist. We have not load-tested these providers or measured their capacity.
A PHP worker count describes part of the site’s request-handling capacity, not a visitor allowance. When a WordPress request needs PHP execution, a worker processes that work. How quickly it finishes and how many such requests arrive together both matter.
What hosts mean by workers or threads
Kinsta’s PHP documentation calls its PHP processes “threads,” previously “workers.” It describes one request being processed by each thread at a time; additional requests wait when all threads are busy. Treat this as the provider’s terminology and model. Ask another host what its advertised worker, process or concurrency number actually measures.
Do not equate workers with CPU cores, database connections or simultaneous visitors. These are separate specifications. Our CPU limits guide and database limits guide explain the other checks.
Why monthly visits do not settle the question
A monthly visitor total does not tell you how many PHP requests arrive together or how long they occupy the available processes. A short burst of checkout requests can have a different workload from the same number of visits spread across a day.
Kinsta’s documentation distinguishes PHP work on uncached requests from cached responses. A cacheable public page can have different requirements from a form submission or private account action. Check the different cache layers and preserve the application’s exclusions for private and transaction pages.
HRL recommends recording representative workflows rather than using a universal visitors-per-worker formula. Include the pages and actions the business depends on, the busiest relevant period and any scheduled work running alongside it.
Collect evidence before changing the count
| Question | Evidence | Decision it informs |
|---|---|---|
| Are requests waiting? | Queue or saturation metrics, if available, at the incident time | Whether concurrency capacity is implicated |
| Which request is slow? | Application trace or timed workflow | Whether code, queries or an external call needs attention |
| Does the request use PHP? | Cache status and route behavior | Whether the worker count is relevant to this response |
| Is another limit reached? | CPU, memory, database and error records | Whether extra workers address the identified constraint |
A timeout or 503 response alone does not prove worker exhaustion. Correlate the affected request with provider metrics and logs. For private pages, follow the logged-in WordPress troubleshooting guide to separate server waiting from browser work.
More workers can involve a memory tradeoff
Kinsta’s PHP performance documentation describes a configurable PHP memory pool. Within that model, allocating the same pool across more threads reduces the memory limit per thread. Its examples include a 2 GB pool split across four threads at 512 MB each or eight at 256 MB each.
Those are documented allocation examples, not measurements of memory used by every request. Do not apply that allocation model to every host. Ask whether changing concurrency also changes memory, price or other limits. Read WordPress memory limits versus server RAM before comparing the numbers.
For background work running alongside visitor requests, trace WordPress scheduled tasks and, where used, Action Scheduler jobs. Record their timing and execution evidence before changing capacity.
Improve the identified workload
HRL recommends addressing a demonstrated cause: an unnecessarily long query, blocking integration or avoidable repeated work. Use supported caching for eligible content, review the schedule of intensive jobs and test changes in an appropriate staging environment. Do not force private or checkout responses into a shared public cache to make a graph look better.
If the essential workload still queues at normal peak demand, compare a confirmed capacity change or another plan. Get the scope, effective limits and recurring charge in writing. Use the stay-or-switch framework for the full cost comparison.
For the broader comparison, use the hosting limits guide index to review storage, database, background work and recovery alongside request capacity.
When the proposed change includes the PHP runtime, use the PHP upgrade checklist to record compatibility and rollback checks separately from worker capacity. For a store, the WooCommerce test-order checklist helps verify the checkout workflow after the change.
A small queue illustration
If two workers are occupied by two slow uncached requests, another request needing those workers may wait under that queueing model. Doubling the worker count does not repair the slow external call inside each request. This is a simplified illustration, not a capacity estimate. Ask for saturation and request-duration evidence together, then investigate whether the workload or concurrency allowance is the relevant constraint.
Kinsta PHP threads and WP Engine worker queues
Kinsta calls its PHP processes threads; WP Engine uses workers and documents request prioritization under heavy uncached traffic. Neither term is a fixed visitors-per-worker allowance. Diagnose slow uncached requests with application traces, queue data and cache behavior before purchasing more capacity. For the practical platform decision, see our Kinsta vs. WP Engine comparison.
Provider guidance checked October 14, 2026: Kinsta PHP documentation and WP Engine worker-queue documentation.
Verify the business result
Repeat the affected workflow under comparable conditions and review both completion and data correctness. Where a load test is needed, agree its scope with the host and use appropriate test accounts and a controlled environment. HRL does not prescribe a worker count for every store; the useful requirement is a supported, demonstrated route for the site’s actual peak work.