How Many PHP Workers Do You Need? A Traffic-Based Sizing Guide (with calculator examples)
Short version: PHP workers are your WordPress site’s assembly line – each worker handles exactly one request at a time. If more requests arrive than you have workers, they queue, users wait, and Core Web Vitals wobble. In this guide, you’ll learn a practical, numbers-first way to size PHP workers for blogs, WooCommerce stores, membership sites, and high-burst campaigns – with clear examples and a simple formula you can adapt to your stack.
Quick tools: Use our hosting cost calculator to map worker counts to pricing tiers, and run your site through the website speed score tool to validate real-world impact after changes. For plan comparisons, see the best hosting providers.
🎥 Watch our short video below which goes in to more detail about How Many PHP Workers You Need.
What a PHP Worker Actually Does (and why queueing hurts)
When a dynamic WordPress request hits your stack (bypassing the page cache or generating a fresh variation), your web server hands it to the PHP-FPM pool. Each PHP worker processes one request from start to finish: bootstrap WordPress, run plugins/theme logic, talk to the database, render HTML/JSON, and return the response.
If you have 4 workers and 10 simultaneous uncached requests arrive, 4 start immediately and 6 wait in the queue. Those 6 users experience latency that has nothing to do with your CPU frequency – it’s pure contention caused by undersized concurrency.Fig. 1 – Requests, workers, and queueing (inline SVG) Incoming Requests Queue (waiting) PHP-FPM Workers
Key insight: Workers are about concurrency, not raw speed. Faster code reduces service time per request, which also reduces the number of workers you need. But when you simply don’t have enough workers for your simultaneous traffic pattern, you’ll see slow TTFB, checkout pauses, and admin-area lag no matter how fast your CPU is.
The Practical Formula for Sizing PHP Workers
Use this back-of-the-envelope rule to get in the right ballpark, then test and iterate with load simulation:
Workers ≈ Peak uncached RPS × Average service time (seconds) × Headroom factor
- Peak uncached RPS: requests per second that bypass page cache (admin, cart/checkout, personalized pages, search, API, cron).
- Average service time: time the worker is “busy” per request. Measure with your APM or PHP-FPM slow log (e.g., 120–600 ms for well-tuned sites; more for heavy plugins/DB joins).
- Headroom factor: 1.3 to 2.0 for burst tolerance and cron jobs. If you have unpredictable spikes, pick 1.7–2.0.
Example: If your WooCommerce store peaks at 5 uncached RPS and each checkout-related request consumes ~300 ms (0.3 s): 5 × 0.3 × 1.6 ≈ 2.4. Round up: start with 3 workers. If concurrency spikes or you run resource-heavy filters, try 4–6.
How Caching Changes the Math
Page caching eliminates most anonymous front-end hits from touching PHP at all. That radically lowers uncached RPS. But in real stores and membership sites, the following remain uncached and do hit workers:
- Cart, checkout, account pages
- Search queries and filters (especially if query string variations aren’t cached)
- WP-Cron tasks, webhooks (Stripe/PayPal), REST API traffic
- Admin screens, editor autosave, media uploads
So a high-traffic blog with excellent page caching might be fine with 2–4 workers, while a moderate-traffic store with chatty plugins might need 6–10 to keep queues empty during sales.
Calculator Walkthroughs (3 realistic scenarios)
Scenario A – Content site with email newsletter spikes
- Traffic pattern: 1,200 users in 10 minutes after newsletter; 90% pages cached, 10% trigger PHP (search, comments, custom shortcodes).
- Peak requests: ~120 uncached requests/minute ≈ 2 RPS.
- Service time: 200 ms average (0.2 s) after performance tuning.
- Headroom: 1.5 for comfort.
Workers: 2 × 0.2 × 1.5 = 0.6 → Round up to 2 workers. Consider 3 if you publish frequently or run heavy cron tasks. Map the cost impact with the hosting cost calculator.
Scenario B – WooCommerce store with flash sale bursts
- Traffic pattern: 300 concurrent visitors at sale open; 30% of requests hit cart/checkout/API uncached.
- Peak uncached RPS: ~6–8 (based on sale telemetry).
- Service time: 350 ms (0.35 s) due to gateway calls and discount rules.
- Headroom: 1.7 to absorb spikes.
Workers: 8 × 0.35 × 1.7 = 4.76 → Start with 5 workers. Validate with a sale rehearsal and monitor queue length. If TTFB jumps above 500 ms under load, move to 6–8. After changes, re-check your website speed score to confirm user-facing gains.
Scenario C – Membership/LMS with heavy logged-in usage
- Traffic pattern: 100–150 concurrent logged-in learners on lesson pages and quizzes; nearly all hits bypass cache.
- Peak uncached RPS: ~4–5.
- Service time: 450 ms (0.45 s) from quiz grading, progress writes, and analytics.
- Headroom: 1.8 (cron + background grading).
Workers: 5 × 0.45 × 1.8 = 4.05 → Start with 5 workers. If you introduce live webinars and webhooks, budget for 6–8.
How many PHP workers do common plans include?
Hosts describe concurrency differently: some quote “PHP workers”, others “concurrent processes”, and some obscure the number behind “plan tiers.” Use the hosting cost calculator to align plan pricing with your required concurrency and the best hosting providers guide to compare stack capabilities (object cache, CDN, autoscaling, burst behaviour). When in doubt, ask the host specifically: “How many PHP-FPM children are provisioned for this plan and what’s the max queue size?”
| Use case | Typical worker starting point | Cache hit rate | Star rating for “worker sensitivity” |
|---|---|---|---|
| Static/Blog with good page cache | 2–3 workers | 85–95% | ★☆☆☆☆ (low) |
| Local business + forms | 3–4 workers | 70–85% | ★★☆☆☆ |
| WooCommerce (small/medium) | 4–6 workers | 40–70% | ★★★☆☆ |
| Membership/LMS | 5–8 workers | 20–60% | ★★★★☆ |
| Enterprise or high-burst sales | 8–16+ workers | Highly variable | ★★★★★ (very high) |
Note: The star ratings above indicate how much your performance depends on worker count – not the inherent “quality” of any host. Validate with synthetic load plus your analytics peaks.
How to Measure Before You Buy More Workers
- Instrument PHP-FPM: Enable the status page and slow logs. Watch
max children reachedand queue depth during peaks. - APM everywhere: Use an APM (New Relic, OpenTelemetry collectors, or your host’s APM) to find average service time and slow endpoints.
- Define “peak” realistically: Pull 95th percentile burst windows from analytics (campaign sends, product drops, TV/radio mentions).
- Load test with cache realism: Warm cache for anonymous pages, but simulate cart/checkout and logged-in flows uncached.
- Re-test your Core Web Vitals: After changes, run the website speed score to confirm the UX impact.
Common Myths (and what actually matters)
- “More CPU cores means I need fewer workers.” Sometimes, but not necessarily. If your bottleneck is I/O (DB, external APIs), extra cores help only when you also allow more concurrency (workers) to overlap waits.
- “Page cache solves everything.” It solves a lot for anonymous users. But logged-in, cart/checkout, and API traffic still consume workers.
- “Workers are the same as requests per second.” Not exactly. Workers limit concurrent PHP execution. With short service times, few workers can satisfy high RPS – until a burst pushes concurrency beyond your ceiling.
- “I can’t oversubscribe.” You can. Too many workers can thrash CPU, memory, and DB connections. Find the sweet spot with APM + tests.
Under- vs Over-Provisioning: Pros & Cons
| Approach | Pros | Cons | Who it suits |
|---|---|---|---|
| Lean (fewer workers) | Lower cost; less memory pressure; forces code efficiency | Queueing during bursts; admin sluggishness; potential checkout delays | Blogs with predictable traffic and strong caching |
| Generous (more workers) | Absorbs spikes; smoother admin; safer for heavy plugins | Higher cost; risk of DB/socket contention if not tuned | Stores, LMS, sites with unpredictable campaigns |
Fine-Tuning Beyond Worker Count
- Object cache: Persistent cache (Redis/Memcached) cuts database calls and reduces service time per request.
- Database hygiene: Add missing indexes, remove N+1 queries, and throttle slow cron jobs. Every millisecond shaved reduces the workers required.
- External calls: Batch or queue non-critical API calls (email, CRM, analytics) so they don’t block user-facing requests.
- Separate concerns: Offload search (Elastic/OpenSearch), image transforms, and background jobs to separate services to keep PHP workers free.
- Autoscaling: If your host supports burstable PHP pools, set reasonable ceilings to avoid runaway costs and DB overload.
Visual: Why shaving service time often beats buying workers
Fig. 2 – Required workers vs service time at constant peak RPS 600 ms 400 ms 300 ms 200 ms ~Rough workers: 6 ~4 ~3 ~2
Assumes peak uncached RPS ≈ 5 and headroom ≈ 1.6.
Step-by-Step: Finding Your Number
- Baseline: Measure your peak uncached RPS and average service time via APM and PHP-FPM metrics.
- Compute: Apply the formula and round up.
- Map to cost: Use the hosting cost calculator to price plan/tier changes.
- Rehearse load: Simulate your real flows (cart, search, login, editor autosave) at peak concurrency.
- Re-measure UX: Validate gains in your website speed score and watch Real User Monitoring.
- Iterate: If queues persist or TTFB spikes, increase workers or reduce service time with code/DB work. Often both.
Buying Guide: Choosing a Plan That Scales
- Transparent concurrency: Prefer hosts who state PHP-FPM children per plan and how they burst.
- Queue visibility: Access to PHP-FPM status and error logs is non-negotiable for serious sites.
- Isolated resources: For stores and LMS, dedicated or containerized pools reduce noisy-neighbour effects.
- Built-in Redis: First-class object cache dramatically lowers service time.
- Autoscaling rules: Understand rate limits, cooldowns, and pricing before a campaign.
- Staging parity: Test worker counts and cron scheduling in staging that mirrors production.
When you’re ready to compare stacks side-by-side, head to our best hosting providers guide.
Troubleshooting Flow (When users shout “slow!”)
- Is the page cached? If no, check worker saturation first; if yes, shift attention to CDN/edge.
- PHP-FPM max children reached? If yes, raise workers (within memory limits) and reduce service time.
- APM traces show DB hotspots? Add indexes, optimise queries, and enable persistent object cache.
- External API delays? Queue non-critical calls; raise timeouts cautiously; cache responses.
- Admin slow only? Throttle heavy dashboard widgets, disable nonessential plugins for admins, and raise workers during editing windows.
How Many PHP Workers Do You Need FAQs
Each worker consumes memory and CPU while it’s busy. More workers increase concurrency at the cost of RAM. If you overshoot, you’ll see swap usage or DB contention. The right number saturates CPU modestly at peak without triggering queue growth.
It can improve TTFB during peaks (which helps LCP), but it won’t fix render blocking, layout shifts, or heavy front-end bundles. Use workers to cure queueing, and apply front-end optimization for CLS/LCP/INP. Validate changes with the website speed score.
They reduce cache effectiveness for logged-in users. Consider fragment caching strategies, modern cart fragments, and ensure CDN and page cache rules are tuned for store pages.
Enable PHP-FPM status or slow logs; look for “max children reached” and growing listen queue. APM “time in queue” is a giveaway. If admin actions lag under edits, you’re likely saturating workers.
Lower service time: enable Redis object cache, optimise queries, cache expensive computations, and trim plugin overhead. Reducing average service time from 400 ms to 250 ms cuts worker needs by ~38% at the same traffic level.
please consider sharing!:
More in Hosting
