PHP Workers, Concurrency, and What They Mean For Your Site

A PHP worker is like a dedicated lane for processing a single request on your website. If all lanes are busy, new requests must wait in a queue, which can lead to slowdowns or errors (like 429s or 504s).

Pressable sites have a dedicated number of workers and can “burst” to handle temporary traffic spikes by borrowing up to 110 workers from a shared pool. The best way to keep your site fast is to use caching, which lets many requests bypass the PHP worker lanes entirely. Another good option is to perform regular plugin audits to reduce “bloat” and lower the risk of poorly optimized or conflicting code.

What is a PHP Worker?

Think of a PHP worker as a helpful assistant dedicated to a single task. It’s a process on the server that executes the PHP code for one website request at a time. While that worker is busy (for example, generating a WooCommerce checkout page), it can’t help with any other requests.

When all workers are in use, any new requests that need a worker must wait in line until one becomes available.

• Fully cached pages that are served from our Edge Cache don’t need a worker’s help at all; they are served directly to the visitor, making them incredibly fast.
• Requests that use Object Cache still require a PHP worker to execute code, but the object cache helps the worker complete its task much faster by reducing the need to query the database.

How PHP Workers Function on the Pressable Platform

• Dedicated Worker Pool: Signature plans include 5 dedicated PHP workers per site (some older plans may have 10). This provides a baseline of processing power that is always available for your site.
• Burst Capacity: To handle sudden traffic spikes, sites can temporarily and automatically scale up to use a maximum of 110 workers per site. This is a “best effort” feature that depends on the server’s overall resource availability.
• Guaranteed Resources: Each worker has 512 MB of RAM and runs on a dedicated CPU core, ensuring reliable performance.
• Consistent Environments: Staging, sandbox, and production sites all use the same server configuration and have the same burst capabilities, so you can test performance reliably.
• Managed Server Environment: The server configuration, including php.ini and NGINX settings, is fixed and managed by Pressable for optimal security and performance. For details on specific limits, please see our PHP info and limitations.

What Uses a PHP Worker (and What Doesn’t)

These actions typically require a PHP worker:

• Any uncached page load (HTML generated by WordPress).
• Most actions for logged-in users (like viewing the wp-admin dashboard or customer-specific content).
• Dynamic requests, such as adding an item to a cart, submitting a form, or using the checkout process in WooCommerce.
• WordPress REST API requests.
• Backend processes, like scheduled posts (wp-cron), running imports, or generating backups with a plugin.

These actions typically do not require a PHP worker:

• Visits to pages served from the Edge Cache (fully cached pages).
• Loading static assets like images, CSS, and JavaScript files.
• Requests that are blocked by the firewall or a security plugin before they reach WordPress.

Common Causes of PHP Worker Exhaustion

When all PHP workers are busy for a sustained period, your site’s performance will degrade. Here are the most common reasons this happens:

• Long-Running Backend Processes: A single, slow task (like a large data export or a complex database query) can tie up a worker for an extended time.
• High-Volume Uncached Traffic: A surge of visitors from a newsletter, social media, or a DDoS attack hitting uncached pages can quickly occupy all available workers.
• Slow Code or External API Calls: Inefficient code in a plugin or theme, or waiting for a response from a slow third-party service (like a real-time shipping rate calculator), can cause requests to take longer, keeping workers busy.
• Caching Misconfigurations: If caching is disabled or a third-party caching plugin is interfering with Pressable’s optimized caching layers, more traffic will hit PHP workers unnecessarily.

Troubleshooting Checklist for Slowdowns

If you suspect your site is running out of PHP workers, follow these steps to diagnose the issue.

1. Check Cache Performance: Use a tool like GTmetrix or your browser’s developer tools to check the response headers of your pages. Look for X-Ac: HIT. A MISS indicates the page is not cached and is using a PHP worker.
2. Review Traffic Sources: Check your analytics or server logs to see if there is a legitimate traffic spike or if the requests are coming from a small number of IP addresses, which could indicate a bot or scraper.
3. Isolate Plugin or Theme Issues: If you recently added or updated a plugin or theme, try deactivating it to see if performance improves. Staging sites are perfect for this kind of testing. See our conflict testing guide for further details.
4. Disable Conflicting Plugins: Pressable’s caching is deeply integrated for performance. To ensure there are no conflicts, disable other performance or caching plugins and re-test. These plugins often cannot use the object-cache.php or advanced-cache.php files on our platform and may actually slow your site down.

Fast Fixes for Common Issues

• Enable ‘Defensive Mode’ in your Edge Cache settings. This can immediately block many sources of illegitimate traffic.
• Manually purge the site cache. This can resolve issues caused by a stale or corrupted cache. Please keep in mind that after the cache is cleared, initial visits will still require PHP workers while the cache is rebuilt.
• Block suspicious IP addresses. If you’ve identified a bad actor, use a security plugin or custom-redirects.php to block the IP.
• Switch to a default theme (like Twenty Twenty-Five). This is a quick way to rule out a theme-related issue, but should be tested on a staging clone first.

For a more detailed guide, see our article on Diagnosing and Mitigating PHP Worker Saturation.

Frequently Asked Questions

Do I need more workers, or do I need faster code?

Always start by optimizing your code and improving your cache coverage. More workers can help with short traffic bursts, but sustained high traffic will always perform better with efficient code that processes requests quickly.

Our guide to troubleshooting performance is a good starting point.

Are WooCommerce pages cacheable?

Generally, product and category pages can be cached for visitors who are not logged in. However, dynamic pages like the cart, checkout, and user account pages will almost always require a PHP worker and thus should be well optimized.

Can I change the PHP limits or NGINX settings?

No. The platform configuration is managed by Pressable to ensure stability and performance for all sites. All optimizations should be done within your WordPress application using plugins and code best practices.

If, after working through optimization steps, the site’s code base and traffic dictate that more PHP workers are needed, you can reach out to Pressable’s sales team to discuss pricing.

Which cache layers are active on my site?

Your site benefits from multiple layers of caching: Edge Caching for global speed, Batcache for serving full-page HTML (via advanced-cache.php), and a persistent object cache backed by Memcache (via object-cache.php).