Diagnosis and removal of PHP overload (503) on the site

Context

• CMS: WordPress + WooCommerce + WPML.

• CDN/WAF: Cloudflare (there is a set of custom rules and rate limits).

• DB: MySQL – stable, “green” (not a bottleneck).

• The web part: 503 errors occur due to PHP overload, not due to the DB (CPU peaks and, importantly, RAM of the web server at the ceiling, there are “failed” → typical OOM and lack of PHP workers).

• Entry processes do not hit the limit → the problem is specifically in PHP processes and memory.

• On the Cloudflare side, WAF/Rate-limit are already in place (blocking add-to-cart bots, protecting /wp-login.php and /wp-admin, xmlrpc is disabled).

Goal

Identify sources of load (URIs/plugins/bots) and eliminate the cause of 503 by optimizing PHP/caching/rules, without losing store functionality.

What needs to be done (step by step)

1) Observation and evidence collection

• Enable detailed PHP logging:

  • php-fpm slowlog (threshold 2–3 s, with stack trace).

  • access-logs with $request_time, $upstream_response_time, response code and user-agent (for nginx/apache).

• Build a TOP list of load-bearing endpoints (GoAccess / awk / any) for the last 24–48 hours:

  • /wp-admin/admin-ajax.php, ?wc-ajax=…, /?rest_route=…, /wp-json/…, add-to-cart, feed, sitemap, etc.

  • Separate bots / suspicious ASNs/countries from real users.

• Check WP-Cron (whether it triggers on every hit), large jobs, image resizing on the fly, PayPal/tracking scripts (SDK should not load on every page).

• 
  

2) Tuning web server/PHP

• Agree on real RAM limits and correctly set PHP-FPM:

  • mode pm = ondemand or dynamic (depending on hosting),

  • pm.max_children, pm.process_idle_timeout, pm.max_requests → so that there are no OOM, but the queue is processed quickly.

• Adjust memory_limit to a realistic value (for example 512M or 256M per process; currently inflated, which only worsens OOM).

• OPcache: confirm adequacy (we have ~512MB, used ~180MB; validate_timestamps ≥ 30–60 s). If necessary, tweak only opcache.memory_consumption, opcache.max_accelerated_files.

• Disable unused browser preloads (warnings in the console) — unnecessary load.

• 
  

3) Caching

• Object-cache: install Redis (or another backend supported by hosting), enable persistent cache for WP.

• Page cache for guests:

  • if the stack allows — enable WP Rocket (or Nginx microcache/LiteSpeed Cache — depending on the environment),

  • on Cloudflare: allow page caching for unauthorized, mandatory bypass for wp-admin, wc-cart, wc-checkout, my-account and by Woo-cookie.

• Disable/move image resizing/generation from “on the fly” to crontab/queue.

• 
  

4) Code/plugins

• Identify and eliminate bottlenecks (using slowlog/Query Monitor/New Relic/Tideways):

  • heavy theme/plugin hooks, large WP_Query, non-optimal meta-queries,

  • duplicate loading of PayPal SDK, “PayPal messaging/Venmo” on all pages — keep SDK only on Cart/Checkout.

• Disable/replace plugins that create disproportionate load.

• Optimize WP-Cron: disable pseudo-cron, set system cron (*/5 * * * * wp cron event run --due-now).

5) Verification and monitoring

• Load test (or real traffic for 24–72 hours) with CPU/RAM graphs and a list of the 5 heaviest endpoints “before/after”.

• Set up alerts (Cloudflare / uptime ping / email from logs) for 5xx and sharp spikes in request_time.

Expected results

1. Diagnostic report: what exactly was loading (URIs/plugins/bots), with examples from logs.

2. Implemented changes with a list (server settings, cache, edits in WP/WAF).

3. Stability: for at least 48 hours under normal traffic:

   • absence of 503,

   • average CPU/RAM load < 70%,

   • P95 TTFB for guest categories/products < 800 ms,

   • clean slowlog (or single cases with explanation).

4. Documentation/rollback (what and where was changed, how to revert).

   
   
   

Backup/staging

• Make a backup before changes.

• Preferably have a staging (or make changes with a maintenance window and instant rollback).

  
  
  
  

Payment

The price for the work is proposed by the performer according to the results of the diagnostics and the actual volume of work.
The project specifies a conditional price.