Диагностика и устранение перегрузки PHP (503) на сайте

Контекст

• CMS: WordPress + WooCommerce + WPML.

• CDN/WAF: Cloudflare (є набір кастом-правил і rate-limit’и).

• БД: MySQL – стабільна, “зелена” (не вузьке місце).

• Веб-частина: 503 з’являються через перевантаження PHP, не через БД (піки CPU і, головне, RAM веб-сервера під стелю, є “failed/невдало” → типові OOM і брак PHP-воркерів).

• Entry processes не впираються в ліміт → проблема саме у PHP-процесах і пам’яті.

• На боці Cloudflare вже стоять WAF/Rate-limit (блок add-to-cart-ботів, захист /wp-login.php та /wp-admin, вимкнено xmlrpc).

Мета

Знайти джерела навантаження (URIs/плагіни/боти) та усунути причину 503, оптимізувавши PHP/кешування/правила, без втрати функціоналу магазину.

Що потрібно зробити (по кроках)

1) Спостереження та збір доказів

• Увімкнути детальне логування PHP:

  • php-fpm slowlog (поріг 2–3 с, зі стеком викликів).

  • access-logs з $request_time, $upstream_response_time, кодом відповіді й user-agent (для nginx/apache).

• Побудувати ТОП навантажувальних endpoint’ів (GoAccess / awk / any) за останні 24–48 год:

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

  • Відокремити ботів / підозрілі ASN/країни та реальних юзерів.

• Перевірити WP-Cron (чи не стріляє кожен хіт), великі джоби, ресайзи зображень на льоту, PayPal/трекінг-скрипти (SDK не має грузитись на кожній сторінці).

• 
  

2) Тюнінг веб-сервера/PHP

• Узгодити реальні ліміти RAM і правильно виставити PHP-FPM:

  • режим pm = ondemand або dynamic (на вибір під хостинг),

  • pm.max_children, pm.process_idle_timeout, pm.max_requests → так, щоб не було OOM, але черга оброблялась швидко.

• Привести memory_limit до реалістичного (наприклад 512M або 256M на процес; зараз завищений, що лише гірше при OOM).

• OPcache: підтвердити адекватність (у нас ~512MB, використано ~180MB; validate_timestamps ≥ 30–60 c). За потреби підкрутити лише opcache.memory_consumption, opcache.max_accelerated_files.

• Вимкнути браузерні preloads, які не використовуються (попередження в консолі) — зайве навантаження.

• 
  

3) Кешування

• Object-cache: встановити Redis (або інший бекенд, який підтримує хостинг), ввімкнути персистентний кеш для WP.

• Page cache для гостей:

  • якщо дозволяє стек — увімкнути WP Rocket (або Nginx microcache/LiteSpeed Cache — залежно від середовища),

  • на Cloudflare: дозволити кеш сторінок для неавторизованих, обов’язково bypass для wp-admin, wc-cart, wc-checkout, my-account і за Woo-cookie.

• Вимкнути/перенести ресайз/генерацію зображень з “на льоту” в crontab/чергу.

• 
  

4) Код/плагіни

• Знайти та усунути вузькі місця (за slowlog/Query Monitor/New Relic/Tideways):

  • важкі хуки теми/плагінів, великі WP_Query, неоптимальні мета-запити,

  • дублікати завантаження PayPal SDK, “PayPal messaging/Venmo” на всіх сторінках — залишити SDK лише на Cart/Checkout.

• Відключити/замінити плагіни, які дають непропорційне навантаження.

• Оптимізувати WP-Cron: вимкнути псевдокрон, поставити системний cron (*/5 * * * * wp cron event run --due-now).

5) Перевірка і моніторинг

• Навантажувальний тест (або реальний трафік 24–72 год) з графіками CPU/RAM і переліком 5 найважчих endpoint’ів “до/після”.

• Налаштувати алерти (Cloudflare / uptime-пінг / e-mail з логів) на 5xx і різкі стрибки request_time.

Очікувані результати

1. Звіт з діагностики: що саме вантажило (URIs/плагіни/боти), з прикладами з логів.

2. Впроваджені зміни з переліком (серверні налаштування, кеш, правки в WP/WAF).

3. Стабільність: протягом щонайменше 48 годин під звичайним трафіком:

   • відсутність 503,

   • середня завантаженість CPU/RAM < 70%,

   • P95 TTFB для гостьових категорій/товарів < 800 мс,

   • slowlog чистий (або одиничні кейси з поясненням).

4. Документація/rollback (що і де поміняно, як повернути назад).
   
   

Бекап/стейджинг

• Перед змінами зробити бекап.

• Бажано мати staging (або робити правки з вікном обслуговування і миттєвим відкатом).
  
  
  

Оплата

Ціну роботи пропонує виконавець згідно результату діагностики та фатичному об'єму роботи.
В проекті вказана умовна ціна.