PHP Workers Explained for Membership Sites, With a Sizing Calculator

A PHP worker is one process on your server that handles one request at a time. If your plan has four workers, four requests run in PHP at once and the fifth waits in line. Membership sites tend to keep more workers busy than a blog with the same traffic, because members’ pages are often personal and skip the page cache, so more of their clicks reach PHP.

To estimate how many you need, multiply the requests that reach PHP per second at your busiest by the average time PHP spends on each, then add headroom for spikes. Ten requests a second that each take PHP 0.4 seconds keep about four workers busy. With 50% headroom, plan for six. The calculator below does the sum with your own numbers.

Sources below are PHP’s own documentation and hosts’ public docs, checked on 19 September 2026. Citing a company’s documentation doesn’t mean it endorses this article, and product names are trademarks of their owners.

What a PHP worker is

WordPress is written in PHP. On hosting that uses PHP-FPM, a process manager runs a pool of PHP processes (some start in advance, some on demand) and each one handles one request at a time. PHP’s manual describes the setting that caps the pool, pm.max_children, as the one that “sets the limit on the number of simultaneous requests that will be served” (PHP manual).

Hosts call these processes different things. Kinsta renamed them: “PHP threads (previously known as PHP workers) are individual PHP processes responsible for handling incoming requests to your website. Each thread processes one request at a time” (Kinsta). WP Engine compares them to shop cashiers: “each cashier handles one customer at a time, just as each PHP worker executes the PHP code that makes up a web page when a request comes in” (WP Engine).

A full-page cache hit served straight from the web server or CDN doesn’t need a worker: the HTML was built earlier. (Some caching plugins still run PHP to serve cached pages, so check how yours works.) That’s why a brochure site can serve a lot of visitors on a couple of workers, and why the count starts to matter the moment people log in.

What happens when every worker is busy

New requests queue. PHP-FPM’s status page even reports the “listen queue”, which it defines as “The number of requests (backlog) currently waiting for a free process” (PHP manual). A short queue shows up as a slow page. A long one turns into errors. WP Engine explains its two: “A 504 error can occur when too many items are in the backlog and items are evicted. A 502 error can occur when items are taking too long to process and are killed to free up the PHP worker for other requests” (WP Engine).

On a membership site the rush tends to come at the worst moments: the cart opens, a course cohort starts, or a live session begins and a crowd logs in within a few minutes.

Why membership sites use more workers

Pressable’s knowledge base has one of the clearest lists of what needs a 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” (Pressable).

Read that list as a membership site owner and much of your members’ activity is on it:

• Member pages. Dashboards, account pages and community feeds are usually specific to each member, so they typically skip the page cache. Lessons may or may not be, depending on your plugins. Kinsta: “The more dynamic a website is, the more PHP threads it will likely need” (Kinsta).
• Checkout and sign-up. WordPress checkout, registration and account-change requests typically run PHP, and payment-provider webhooks can add more PHP requests, depending on the integration.
• Background requests. On pages where WordPress or a plugin loads the Heartbeat API, it keeps checking in with the server, on “an interval (called the ‘tick’) to run every 15-120 seconds”, and “an admin-ajax handler” answers each check (WordPress). Course and community plugins can add their own AJAX or REST calls on top, for example to save progress or check notifications. Your browser’s network tab shows which ones your site makes.
• Scheduled jobs. WordPress’s WP-Cron is triggered by site visits by default (WordPress), and jobs that plugins schedule through it, such as reminder emails, run as PHP requests too.

None of this is a problem on its own. It becomes one when your busiest minute needs more workers than your plan has.

How many PHP workers do you need?

It starts with two numbers only your site can give you: how many requests reach PHP at peak, and the average time PHP spends on each. Memory and CPU then set limits on the answer. The relationship between them comes from queueing theory. Little’s Law says the average number of items in a system equals the arrival rate multiplied by the time each item spends in it, “L = λW” (Wikipedia, citing Little 1961). For a PHP pool that becomes:

workers busy on average = requests reaching PHP per second × average PHP time per request, in seconds

Little’s Law works with averages, so use the mean time per request, not a percentile. Then add headroom, because traffic doesn’t arrive evenly: a launch minute is lumpier than the average suggests.

Memory is the second limit. Each worker holds its own memory, so the pool has to fit in the RAM left over after the database and web server. Tideways, a PHP profiling company, puts the rule as “(Total RAM - Memory used for Linux, DB, etc.) / process size” (Tideways). CPU is the third. A worker waiting on the database or an outside service barely uses the CPU, so a pool can hold more workers than the server has cores, but requests that are busy computing compete for those cores. Check CPU use at peak before you grow the pool.

How to measure your own numbers

The calculator is only as good as what you put in. Three places to get real figures:

1. PHP-FPM’s access log. It logs only requests that reached PHP, and its format can include %d, the “time taken to serve the request”, and %M, the “peak of memory allocated by php” (PHP manual). Count the entries in your busiest minute and average %{milliseconds}d over the same entries (plain %d is in seconds), and you have the calculator’s first two inputs. %M shows how much memory PHP allocated for a request, which is less than the whole worker process uses, so ask your host for the worker processes’ real memory under load for the memory check. Your host can switch the fields on if they aren’t there.
2. The PHP-FPM status page. It shows how many processes are active and idle, the listen queue, and “max children reached” (PHP manual). A value above zero means the pool has hit its limit since PHP-FPM last restarted. Check whether that lines up with slow pages or errors in the same period. If your host doesn’t give you access to it, ask them to read it for you.
3. Query Monitor. It isn’t a sizing tool, since it reports the page you’re looking at rather than your real traffic, but it’s the quickest way to see why a slow page is slow: the queries, plugins and time behind it (Query Monitor). Making slow requests faster cuts the workers you need as surely as adding more.

Before you buy more workers

More workers only help when requests are waiting for a free worker. If each request is slow because of one heavy query or a plugin doing too much work, more workers mean more slow requests running at once, all competing for the same CPU and database. Two questions to ask first:

• Are requests slow, or queued? Slow pages with an empty listen queue point at the requests themselves: profile them before changing anything, whether the fix turns out to be code, queries or caching. A queue that grows at peak means the pool is full; look at request time, the database, outside calls, CPU and memory before simply adding workers.
• Does your plan’s CPU match the worker count? A large worker number on a small server moves the queue from PHP to the CPU.

“Unlimited” worker plans deserve the same question. The limit moves to CPU, memory or the host’s fair-use terms, so ask what caps your site at peak.

How we size it

We don’t sell fixed plan tiers (how pricing works), so there’s no worker count to pick from a pricing table. We size hosting to each site, and configure and tune caching per site. On MemberPress sites we test object caching first, since MemberPress warns against it. We load test with tools like loader.io and k6, as our concurrent users page describes. If you’d like us to look at yours, start with our free site speed audit.

Frequently Asked Questions

What is a PHP worker in WordPress?

A PHP worker is a server process that runs WordPress’s PHP code for one request at a time. The number of workers caps how many requests PHP can handle at the same moment. Pages served from a full-page cache without running PHP don’t use one.

How many PHP workers do I need for a membership site?

Multiply the requests that reach PHP per second in your busiest minute by the average PHP time for each, then add headroom for spikes. Ten requests a second at 0.4 seconds each keep four workers busy; with 50% headroom that’s six. The calculator on this page does the sum with your own numbers.

What happens when PHP workers run out?

New requests wait in a queue until a worker is free, so pages slow down. If requests wait or run too long, visitors can get timeouts or gateway errors; which error depends on the hosting stack. On membership sites this tends to happen when many members log in at once, such as a launch or a live session.

Do more PHP workers make a site faster?

Only when requests are queuing for a free worker. If each request is slow on its own, more workers let more slow requests run at once and compete for the same CPU and database. Fix the slow requests first, then size the worker pool.

What is the difference between PHP workers and PHP memory limit?

Workers set how many requests run at the same time. The memory limit sets how much memory a single request may use. Kinsta puts it as threads managing “concurrency” while the memory limit “manages resource allocation by restricting the memory usage of individual scripts” (Kinsta).