How Kinsta handles PHP threads and caching for WP performance

Surface-level feature lists rarely tell the complete story when you evaluate managed WordPress hosting for development. You need to understand how PHP thread allocation impacts concurrent request handling, how multiple caching layers work together to reduce database load, and whether containerization actually prevents problems under real-world conditions.

This guide breaks down Kinsta’s technical architecture for PHP thread management, multi-layer caching, and container isolation. We also include quotes from Nikola Djuric, a senior support engineer on the Kinsta team, on the intricacies of PHP thread management.

Let’s start with how PHP actually handles requests.

Understanding PHP threads and why they matter for WordPress performance

PHP threads process incoming uncached requests. Each thread handles one request at a time, so your available thread count directly affects how many visitors your site can serve simultaneously.

When a visitor loads an uncached page, submits a form, or adds an item to their cart:

1. The web server receives the request and hands it to PHP-FPM.
2. PHP assigns the request to an available thread.
3. That thread executes the PHP code, fetches database data, and generates dynamic output.
4. Once complete, the thread becomes available again.

Most people do not know that an uncached request uses one PHP thread and that processing speed depends on PHP plus MySQL response time.

Cached requests skip this entire process (they don’t touch PHP at all), which is why cache HIT rates are the single biggest factor in how many threads you actually need.

WooCommerce sites, membership dashboards, REST API traffic, and headless setups all bypass caching far more often, which means they consume threads quickly.

For example, if your average API response takes 250 milliseconds, each thread can process four requests per second. With eight threads, your theoretical maximum throughput is 32 requests per second. However, this is only if every request completes in exactly 250ms.

How concurrent traffic consumes PHP threads

Your thread count matters most during concurrent traffic. If your site has four threads and receives six simultaneous uncached requests:

• Four requests start processing immediately.
• Two wait for a free thread.

If new traffic arrives faster than threads can free up, the backlog grows.

Slow database queries make this worse. For example, a database query that takes 10 seconds locks one thread for that entire duration. If you receive three concurrent requests that each trigger slow queries, you’ve consumed three threads for a total of 30 seconds. During that time, your remaining threads handle all other traffic.

When you add WooCommerce filters, account pages, or checkout workflows, thread pressure climbs even higher.

For PHP threads, simple sites need only four. But for e-commerce, anything under six is low because of the high bypass cache ratio.

The relationship between thread count and execution time

A rough way to estimate thread needs:

Required threads ≈ (Uncached Requests per Second × Average Execution Time)

Based on this, a site with 10 uncached requests per second and an average execution time of 0.5 seconds needs approximately five threads to handle the load without queuing.

This explains why simply adding more threads doesn’t guarantee better performance. If slow database queries cause your average execution time to climb from 0.5 seconds to two seconds, your thread requirements quadruple.

The solution is faster code execution. Optimizing queries, reducing external API calls, and implementing proper object caching can dramatically reduce execution time and the threads needed to handle your traffic.

PHP thread allocation across Kinsta plans

Kinsta assigns PHP threads based on the CPU and RAM resources available to each site’s container (every Kinsta site runs in its own LXD container, so resources are isolated).

General patterns across plans:

• Entry-level: 2–4 threads at 256MB per thread. This is ideal for blogs and static content sites with high cache HIT rates.
• Mid-tier: 6–8 threads at 256MB per thread, with some agency plans increasing memory to 512MB per thread.
• Upper-tier: 10–16 threads with 512MB per thread, suitable for high-traffic or complex sites.
• Multisite: 8–14 threads depending on tier.

You can adjust thread allocation inside MyKinsta > Info > PHP performance, increasing the memory pool or thread count based on your site’s traffic patterns.

This flexibility lets you tune PHP to your actual workload, rather than relying on defaults.

Estimating PHP thread requirements for your site

Different site types need custom thread allocations based on how much traffic bypasses the cache:

• Static content sites. 2–4 threads are usually enough because cached pages serve almost all traffic.
• WooCommerce stores. Start with 8–12 threads depending on catalog size, filtering complexity, and checkout volume.
• API-heavy or headless apps. Estimate based on execution time (e.g., 0.25s requests = about 4 per second per thread).
• Membership sites and LMS platforms. Logged-in users bypass caching entirely, so they behave similarly to e-commerce.

The analytics within MyKinsta helps you identify your current thread usage patterns.

If you see request queuing or timeout errors during high-traffic windows, your thread allocation likely needs adjustment.

What happens when you exceed your PHP thread limit

Thread exhaustion follows a predictable pattern:

There is no queue for requests. The number of PHP threads your site has determines how many uncached requests can be processed at once. When a request comes in and no thread is available, it waits for a thread to free up. If that doesn’t happen quickly enough, you’ll see 502 or 503 bad gateway timeout errors.

Typical symptoms:

• Requests queue inside NGINX/PHP-FPM when all threads are busy processing.
• End users experience delay first, such as spinning loaders, slow checkout steps, or broken AJAX calls.
• 502 or 504 errors appear once the queue capacity fills completely.
• Recovery typically happens within 30–120 seconds after slow functions finish and the cache ‘warms’.

Slow database queries are the most common cause.

Slow database queries take more time to be processed by PHP threads and that’s how they typically kill site performance.

External API calls create similar problems. Payment gateways, tax calculation services, and shipping APIs frequently block threads during checkout.

Diagnosing thread exhaustion requires examining multiple data sources. Kinsta’s APM Tool traces slow requests and identifies bottlenecks, while slow query logs reveal database performance problems. Nginx queue metrics show request backlog patterns and cache HIT/MISS ratios indicate whether your caching is working.

The solution is to optimize the execution time:

• Slow database queries need indexing, query optimization, or reduced query counts.
• Heavy plugins might require replacement with lighter alternatives.
• Cron tasks should shift to off-peak hours.
• External API calls benefit from caching, background processing, or circuit breakers.

Optimization should come before adding more threads. Increasing thread count only helps after average execution time is under control.