Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Cache Php Mysql Hosting

PHP Workers Are Exhausted During WordPress Traffic Peaks

Diagnose WordPress PHP worker exhaustion by correlating queues, slow requests, cache misses, cron and traffic before increasing capacity.

During a campaign or busy hour, static files remain available but WordPress pages wait or return 502/503 errors. All PHP workers may be busy. Increasing the worker limit can help only if CPU, memory and the database can support more simultaneous requests.

First find what occupies each worker and why traffic reaches PHP.

Confirm queueing rather than a general outage

Correlate the incident time across web server, PHP-FPM and hosting metrics. Look for reached-process warnings, listen-queue growth, gateway timeouts and slow PHP responses.

Compare a static file with a dynamic uncached URL. If static delivery is fast while PHP waits, the application pool is a strong suspect. If both fail, investigate server or network capacity more broadly.

Use timezone-aware timestamps. CDN, server and analytics logs may not share the same timezone.

Measure concurrency and request duration

Worker demand is approximately driven by concurrent PHP requests multiplied by how long each occupies a process. Ten fast requests can be easier than two slow external API calls that each block for seconds.

Review slow logs or application traces for the peak window. Group requests by route: homepage misses, admin-ajax.php, REST API, checkout, cron and bots.

Do not log full request bodies or payment data. Paths, durations and response status are usually enough.

Check cache hit rate at the same moment

A full-page cache purge during a traffic spike can send every visitor to PHP. So can a cookie or query parameter that bypasses cache.

Inspect cache hit/miss metrics and invalidation events. Confirm whether a content publish, stock update or deployment cleared broad caches immediately before the queue formed.

Protect dynamic WooCommerce routes, but improve cacheability for genuinely public pages. Never cache checkout HTML to reduce worker use.

Look for slow external calls

SMTP, licence checks, remote feeds, currency services and tracking APIs can block PHP workers while waiting for another server. Application traces or PHP slow logs can reveal network functions in the stack.

Set sensible timeouts and move non-essential work to a background job where the plugin supports it. Do not suppress a required payment response or webhook verification.

Cache stable remote data with explicit expiry and failure behaviour.

Inspect cron and asynchronous jobs

WordPress cron, Action Scheduler and backup jobs can launch many PHP requests at once. Match job logs to the saturation window.

Run heavy recurring work outside visitor-triggered page requests where hosting allows, and prevent duplicate runners. Stagger backups, image regeneration and feeds away from known peaks.

Do not delete pending WooCommerce actions indiscriminately. They may represent emails, payments, subscriptions or stock updates.

Assess worker limits with memory and CPU

Each PHP process consumes memory, and concurrent processes compete for CPU and database connections. Review actual peak memory per worker and total server headroom.

Raising pm.max_children without capacity can create swapping and make every request slower. On managed hosting, worker counts may be enforced by plan; provider metrics can show limit hits.

Reduce per-request duration and unnecessary PHP traffic before purchasing capacity, then size the pool from measured demand.

Prepare graceful peak behaviour

Warm critical public pages after controlled purges, rate-limit abusive endpoints and ensure the CDN can absorb static traffic. Protect login and expensive search without blocking legitimate customers.

Use a maintenance or queue message only when necessary and avoid retry loops that increase load. Monitor error rate, queue and successful checkout outcomes during the next peak.

When urgent intervention is justified

Request urgent performance repair when orders fail, PHP-FPM logs show repeated pool exhaustion or the root route is unclear. Share incident times, sanitised logs and affected URLs first.

A responsible repair should reduce the work holding workers, preserve dynamic ecommerce behaviour and only then recommend additional capacity based on evidence.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident