Контекст 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. Очікувані результати Звіт з діагностики: що саме вантажило (URIs/плагіни/боти), з прикладами з логів. Впроваджені зміни з переліком (серверні налаштування, кеш, правки в WP/WAF). Стабільність: протягом щонайменше 48 годин під звичайним трафіком: відсутність 503, середня завантаженість CPU/RAM < 70%, P95 TTFB для гостьових категорій/товарів < 800 мс, slowlog чистий (або одиничні кейси з поясненням). Документація/rollback (що і де поміняно, як повернути назад). Бекап/стейджинг Перед змінами зробити бекап. Бажано матиstaging (або робити правки з вікном обслуговування і миттєвим відкатом). Оплата Ціну роботи пропонує виконавець згідно результату діагностики та фатичному об'єму роботи. В проекті вказана умовна ціна.