PHP Worker & Concurrency Calculator
Enter your traffic and site type to find out exactly how many PHP workers, how much RAM, and how many CPU cores your WordPress site actually needs — before a traffic spike finds out for you.
“Unlimited” hosting plans do not mean unlimited PHP. Every WordPress host, from the cheapest shared plan to a fully managed enterprise box, caps the number of PHP-FPM workers your site can run at the same time — and that ceiling, not your CPU or RAM headline, is usually what falls over first during a traffic spike. This calculator works backward from your real traffic and site type to tell you the PHP workers, RAM, and CPU cores your site needs, and which hosting tier can actually deliver them.
Enter your traffic and site details below. We calculate concurrent PHP load the same way server admins size PHP-FPM pools manually.
If you’re writing about WordPress hosting or PHP-FPM sizing, here’s a ready-to-paste link to this calculator.
How this calculator works
Most hosting calculators only ask how much traffic you get. That misses the number that actually determines whether your site survives a spike: how many of your visitors are hitting PHP at the same moment, rather than being served a cached page that never touches your server’s CPU. This tool estimates that concurrent PHP load from your traffic and site type, adds a safety buffer for bursts, and converts the result into PHP workers, RAM, and CPU cores — the same three numbers a server administrator would size a PHP-FPM pool around.
A PHP worker (technically a PHP-FPM child process) can handle exactly one request at a time. If your host allows 6 workers and a 7th dynamic request arrives, it queues behind the others. Once that queue backs up, visitors start seeing 502 or 504 gateway errors, or a blank white screen — not because your site is “down,” but because every worker is already busy.
A full-page cache or CDN serves logged-out visitors a static copy of the page without ever waking up PHP or MySQL. That is why a well-cached blog can handle enormous traffic on modest hosting, while a WooCommerce store or membership site — where carts, checkouts, and logged-in dashboards cannot be cached — needs dramatically more headroom at the same visitor count.
This calculator adds 40% headroom on top of your calculated average concurrent load. Real traffic is bursty — a Reddit mention, an email send, or a flash sale can double your concurrent visitors within minutes. Sizing to your exact average leaves zero room for that, which is precisely when sites go down.
Reading your results
Understanding what each number means helps you use this for more than one calculation.
This is the number of simultaneous PHP-FPM processes required so that a visitor never queues behind another during your normal traffic peaks. It is driven almost entirely by how much of your traffic is dynamic — a WooCommerce store or membership site converts a much larger share of its visitors into real PHP workers than a cached blog with identical traffic.
Each PHP worker holds its own chunk of memory while WordPress, your theme, and your plugins are loaded — more plugins and heavier page builders mean more RAM per worker. The total adds your workers’ combined memory to a baseline for MySQL and the web server itself, then rounds up to a realistic hosting plan size.
PHP execution is a mix of CPU time and waiting on the database, so a single core can typically serve several workers at once rather than one worker per core. This estimate accounts for that ratio, plus one core of overhead for the operating system, web server, and database.
Rerun it whenever your traffic roughly doubles, before a planned traffic event (a launch, a sale, a press mention), or if you add a page builder, a large plugin, or WooCommerce to a site that did not previously have one. Any of those changes shifts the inputs enough to change the recommended tier.
Frequently asked questions
A PHP worker is a PHP-FPM child process that can execute exactly one PHP request at a time. Your hosting plan (or server configuration) sets a maximum number of workers, controlled by the pm.max_children setting. When every worker is busy handling a request, any new dynamic request has to wait in a queue until one frees up — that queue is what causes slowdowns and 502/504 errors during traffic spikes, not the traffic itself.
A small, well-cached blog can often run comfortably on 2 to 4 workers because full-page caching handles the vast majority of requests without touching PHP. A WooCommerce store or membership site with the same traffic can need 3 to 5 times that, because carts, checkouts, and logged-in account pages cannot be served from a page cache. There is no single universal number — it depends on traffic, how much of the site is cacheable, and how heavy your plugin stack is, which is exactly why this calculator asks for all three.
No. RAM and worker count are related but controlled separately. A server can technically have enough free RAM to run 30 workers, but if the hosting plan’s PHP-FPM pool is configured to allow only 6, the extra RAM sits unused during a traffic spike. This is the core reason “upgrade your RAM” advice often does not fix crash-during-spike problems — the PHP-FPM worker limit needs to be raised as well, which usually requires a hosting tier that allows server-level configuration.
Product pages can often be cached like any other page, but the cart, checkout, “my account,” and the AJAX calls that update cart totals and stock levels cannot be — they have to be generated fresh by PHP for every single visitor, every single time. That converts a much larger share of your traffic into real PHP workers compared to a blog, where the same visitor would mostly be served a cached page.
“Unlimited” almost always refers to bandwidth or storage, not simultaneous PHP execution. Nearly every shared hosting plan — regardless of how it is marketed — hard-caps PHP-FPM workers at a low number, typically around 4, to keep many customers on the same physical server from affecting each other. This calculator flags anything above 4 workers for that reason: it leaves a small margin before you hit that ceiling rather than waiting until you are already over it. If your result is higher, the plan itself is the limit, not something an upgrade within the same shared tier will fix.
The calculator assumes your busiest hour of the day accounts for roughly 15% of that day’s total visits — a commonly cited traffic-distribution figure — and combines that with a typical session length for your site type (longer for membership and WooCommerce sites, shorter for a blog) to estimate how many people are on the site simultaneously at peak. It is a reasonable starting point, but a real number from Google Analytics’ real-time report, or your host’s live visitor stats, will always be more accurate for your specific site.
Yes. Re-run the calculator whenever your traffic roughly doubles, before any planned traffic event such as a product launch or a marketing send, and any time you add WooCommerce, a membership plugin, or a heavy page builder to a site that did not previously have one. Any of those changes can shift you into a different hosting tier.
A CPU core is physical processing capacity; a PHP worker is a software process that uses a share of that capacity while it runs. Because PHP requests spend part of their time waiting on the database rather than using the CPU continuously, one core can typically support several workers at once — this calculator uses that ratio, adjusted for how heavy your plugin stack is, to translate your worker count into a core recommendation.
Your server specs shouldn’t be a guess.
Hosting plans are sold on storage, bandwidth, and CPU numbers that sound generous but say nothing about how many PHP requests your site can actually handle at once. The PHP-FPM worker limit is the number that determines whether your site survives a traffic spike — and it is rarely the number advertised on the pricing page.
Know your real numbers before your next traffic spike finds the gap for you.