PHP Worker & Concurrency Calculator
Work out how many PHP workers, how much RAM and how many CPU cores your WordPress site needs at its busiest hour, see what happens when traffic spikes, and get a starting PHP-FPM configuration.
âUnlimitedâ hosting doesnât mean unlimited PHP. Every plan limits how many PHP requests can run at the same time, and that limit, along with the CPU and RAM behind it, is often what gives way first in a traffic spike. This calculator uses Littleâs Law, the standard queueing formula: requests running at once = requests per second Ă time per request. It works from your peak traffic, how much of it your page cache absorbs and how long PHP takes per request, and every step is shown in the results.
Defaults are example starting points. Replace them with your own numbers from analytics, your cache stats and your hostâs dashboard.
Writing about WordPress performance, PHP-FPM or choosing a host? Copy a link, or embed the working calculator on your own page. Every result also has its own shareable link.
How this calculator works
A PHP worker (a PHP-FPM child process) handles one request at a time. If all workers are busy, the next PHP request waits. When the queue grows, visitors see slow pages or 502/504 gateway errors, even though the server is âupâ.
A page cache or CDN serves stored copies of pages without running PHP. Thatâs why a well-cached blog can handle a lot of traffic on a small plan, while a store or membership site, where carts and logged-in pages bypass the cache, needs far more PHP capacity at the same traffic.
Halving PHP response time halves the workers you need. Faster code, an object cache and fewer heavy plugins add capacity just like a bigger plan does.
Published PHP worker limits
Many hosts donât publish a PHP worker number at all. These two do. Figures from each hostâs own documentation, checked October 2026; plans and limits change, so check before you buy.
| Host | Plan | PHP workers | Also included |
|---|---|---|---|
| Hostinger | Web Single (shared) | 20 PHP workers | 1 CPU core, 1 GB RAM |
| Hostinger | Web Premium (shared) | 40 PHP workers | 1 CPU core, 2 GB RAM |
| Hostinger | Unlimited (shared) | 60 PHP workers | 2 CPU cores, 3 GB RAM |
| Hostinger | Cloud Startup | 100 PHP workers | 4 CPU cores, 4 GB RAM |
| Hostinger | Cloud Professional | 200 PHP workers | 5 CPU cores, 6 GB RAM |
| Kinsta | Single 35k visits | 2 PHP threads per site | 512 MB PHP memory pool |
| Kinsta | Single 65k visits, WP 5, WP 10 | 4 PHP threads per site | 1 GB pool |
| Kinsta | Single 125k & 315k visits, WP 20, WP 40 | 6 PHP threads per site | 1.5 GB pool |
| Kinsta | Single 500k & 750k visits | 8 PHP threads per site | 2 GB pool |
| Kinsta | Single 1.25M visits, WP 80 | 10 PHP threads per site | 5 GB pool |
| Kinsta | Single 3.15M visits | 16 PHP threads per site | 8 GB pool |
Kinstaâs threads are per site and can be rebalanced against memory per thread or increased with its PHP Performance add-on. Hostinger lists PHP workers per hosting plan alongside its CPU and RAM limits.
Example results
Worked examples using the calculatorâs formulas and defaults (10% of daily traffic in the busiest hour, 100% headroom, 80 MB per process). The sites are illustrative. Click a row to load it and change the numbers.
| Example | Peak pageviews / hour | PHP workers | RAM | CPU cores | |
|---|---|---|---|---|---|
| Cached blog 1,000,000 pageviews a month, 90% served from page cache, 400 ms PHP time | 3,333 | 2 | 2 GB | 1 | Open in calculator |
| WooCommerce store 300,000 pageviews a month, 50% cached, 1.5 extra AJAX/REST requests per pageview, 800 ms | 1,000 | 2 | 2 GB | 1 | Open in calculator |
| Busy WooCommerce store 3,000,000 pageviews a month, same settings as above | 10,000 | 9 | 2 GB | 5 | Open in calculator |
| Membership / LMS site 1,000,000 pageviews a month, 20% cached, 1 extra request per pageview, 700 ms | 3,333 | 3 | 2 GB | 2 | Open in calculator |
Reading your results
How many PHP requests your site should be able to run at the same moment at its peak, including headroom. On your own server this is the value for pm.max_children; on managed hosting, compare it with your planâs published worker or thread limit.
Workers Ă typical memory per process, plus memory for the database, web server and operating system, rounded up to a common server size. Use real per-process memory, not your PHP memory_limit, which is a ceiling.
The processing PHP needs at your peak. If the database runs on the same server, it needs CPU of its own on top.
The chart repeats the calculation at 2, 3, 5 and 10 times your peak. If you enter your planâs worker count, you also see the traffic it can handle at your settings.
Sources
- PHP-FPM settings: PHP Manual, FPM configuration: pm.max_children âsets the limit on the number of simultaneous requests that will be servedâ; pm.start_servers defaults to (min_spare_servers + max_spare_servers) / 2.
- Littleâs Law: John D. C. Little, âA Proof for the Queuing Formula: L = ÎťWâ, Operations Research, 1961. The average number of requests in a system equals the arrival rate times the average time each spends there.
- Kinsta: Kinsta plans and PHP threads and PHP Performance (including the 128 MB per thread recommendation for WooCommerce).
- Hostinger: Parameters and limits of hosting plans.
- Our assumptions: example cache rates, extra requests, response time, memory per process, headroom, the 10% busiest-hour share, the hosting-tier bands and the spare-server values in the configuration are PaidHosting.comâs illustrative defaults, not measured averages. Checked October 2026.
PaidHosting.com. (2026). PHP Worker & Concurrency Calculator. Retrieved from https://www.paidhosting.com/php-worker-calculator/
Frequently Asked Questions
A PHP worker is a PHP-FPM child process. Each one runs one PHP request at a time. The maximum number is set by the pm.max_children setting, which the PHP manual describes as the limit on the number of simultaneous requests that will be served. When every worker is busy, new PHP requests wait in a queue; long queues show up as slow pages and 502 or 504 errors.
It depends on how many uncached PHP requests arrive per second at your peak and how long each takes. Multiply the two to get the number running at once, then add headroom for bursts. A well-cached blog with a million pageviews a month can need as few as 2 workers, while a busy WooCommerce store with the same traffic can need several times more, because carts, checkouts and account pages are normally excluded from page caching. The calculator shows the maths for your numbers.
No. RAM limits how many workers can run safely, but the worker count itself is a separate setting (pm.max_children on your own server, or your planâs published limit). Extra RAM sits unused if the worker limit is low, and raising the worker limit without enough RAM or CPU just moves the bottleneck.
Product and category pages can often be cached, but the cart, checkout, âMy accountâ pages and the background requests that update cart totals are generated by PHP for each visitor. That turns a much larger share of traffic into PHP work. Kinstaâs documentation also recommends at least 128 MB of memory per PHP thread for WooCommerce sites.
âUnlimitedâ normally refers to bandwidth or storage. PHP is limited by the planâs worker (or process) limit, CPU and RAM. Limits vary a lot between hosts and plans: for example, Hostinger publishes 20 PHP workers with 1 CPU core and 1 GB of RAM on its Web Single plan, while Kinsta publishes 2 to 16 PHP threads per site depending on the plan. Compare your calculated number with your planâs published limits, CPU and RAM.
Use your analytics toolâs hourly report and find the busiest hour of a normal busy day. If you only know monthly pageviews, the calculator divides by 30 days and applies the share of a day that falls in the busiest hour. Traffic spread evenly would put about 4.2% of a day in each hour; real sites usually see more than that in their peak hour, which is why the example default is 10%.
Measure the time to first byte of pages that are not served from cache, for example while logged in or on the cart page, or use a profiling plugin such as Query Monitor to see how long WordPress takes to generate a page. Your hostâs monitoring or the PHP-FPM slow log can also show it. Use an average across typical uncached pages, not your fastest or slowest one.
A CPU core is processing capacity; a PHP worker is a process that uses some of it while handling a request. Part of each request is spent waiting on the database or other services, not using the CPU, so one core can keep more than one worker busy. The calculator multiplies the requests running at once by the share of time spent on the CPU to estimate the cores PHP needs.
Your server specs
shouldnât be a guess.
Hosting plans are sold on storage, bandwidth and CPU numbers that say little about how many PHP requests your site can handle at once. The PHP worker limit, with the CPU and RAM behind it, decides whether your site stays up in a traffic spike, and it is rarely the number on the pricing page.
Know your real numbers before
your next traffic spike finds the gap.