Головна сторінка відкривається швидко, але кошик, пошук або вхід у WordPress зависають під час одночасних звернень? Навіть за помірного навантаження на процесор сайт може вичерпати кількість доступних PHP workers — процесів, які виконують динамічні запити. Нові звернення тоді чекають у черзі або завершуються помилкою.
Для власника бізнесу це виглядає як вибірковий збій: реклама приводить людей, каталог працює, а оформлення замовлення недоступне. Щоб відновити сайт, потрібно підтвердити саме обмеження паралельної обробки та знайти, чому процеси надовго зайняті.
Що означає ліміт PHP workers
Один робочий процес обробляє PHP-запит і звільняється після його завершення. Поки він чекає відповідь CRM, бази даних або стороннього API, він може залишатися зайнятим. Через це всі процеси здатні вичерпатися навіть тоді, коли CPU не завантажений на 100%.
Готова сторінка з повного кешу часто віддається без запуску WordPress, тому головна може працювати, коли особистий кабінет уже не відповідає. Ліміт процесів не дорівнює кількості відвідувачів: одна людина може створити кілька запитів, а багато відвідувачів кешованих сторінок — майже не залучати PHP.
Як підтвердити, що проблема саме в черзі
Запишіть точний час збою з часовим поясом, проблемний URL і дію користувача. Попросіть хостинг зіставити цей період із кількістю активних PHP-процесів, довжиною черги та випадками досягнення ліміту. Сам код 502, 503 або 504 не доводить нестачу workers: його можуть спричиняти й інші помилки.
У середовищі PHP-FPM корисні журнали пулу, slowlog і повідомлення про досягнення pm.max_children. Цей параметр визначає верхню межу дочірніх процесів, що обслуговують одночасні запити; деталі описано в офіційній документації PHP-FPM. На спільному хостингу показники та назви обмежень можуть відрізнятися.
- Чи збігається початок черги з помилками у клієнтів?
- Які запити найдовше утримують процеси?
- Чи є в цей час очікування бази даних або зовнішнього сервісу?
- Чи зникає збій після завершення імпорту, резервного копіювання або синхронізації?
Які функції WordPress найчастіше утримують процеси
Перевіряйте конкретні операції: складний пошук, фільтрацію товарів, запити admin-ajax.php, REST API, генерацію документів і синхронізацію залишків. Важливі не лише частота звернень, а й тривалість кожного. Кілька повільних операцій можуть зайняти весь доступний пул.
Окремо перевірте інтеграції, що очікують відповідь стороннього сервісу без розумного обмеження часу. Якщо CRM недоступна, сайт не повинен безконтрольно накопичувати однакові повторні звернення. Водночас зміни в обробці оплат потребують перевірки статусів і захисту від повторного виконання.
Зіставте довгі запити з фоновими завданнями. Перенесення імпорту на тихі години може зменшити конкуренцію за ресурси, але задачу, яка зависає або нескінченно повторюється, потрібно виправляти окремо.
Як зменшити чергу без порушення роботи магазину
Почніть із підтверджених причин: скоротіть час повільного запиту, виправте повторні виклики, налаштуйте таймаути інтеграцій і розмір пакетів обробки. За потреби винесіть тривалі операції у контрольовані фонові завдання з відстеженням результату.
Перевірте кешування публічних сторінок. Зайві cookies або невдалі правила можуть обходити кеш для всіх відвідувачів. Кошик, оформлення замовлення та персональні дані не можна механічно кешувати як загальнодоступні сторінки — це створить функціональні помилки й ризик показу чужої інформації.
Якщо джерело — автоматизовані звернення, обмежуйте конкретну небажану активність. Повне блокування REST API чи admin-ajax.php без аналізу може зупинити потрібні функції WordPress. Простий перезапуск PHP лише звільнить процеси на певний час, якщо причина залишилася.
Коли збільшувати кількість workers або змінювати тариф
Розширення ресурсів виправдане, коли запити вже працюють нормально, але реальний одночасний попит перевищує можливості поточної конфігурації. Для рішення потрібні вимірювання тривалості запитів, використання пам’яті та стану бази даних.
Безконтрольне збільшення кількості процесів може вичерпати RAM або посилити навантаження на MySQL. Узгодьте з хостингом доступний запас ресурсів і спосіб повернення попередніх налаштувань. Сам перехід на дорожчий тариф не виправляє завислу інтеграцію.
Як перевірити результат і замовити ремонт
Після виправлення повторіть проблемний сценарій за узгодженої кількості одночасних звернень. Перевірте час очікування, чергу, частку помилок і запас вільних процесів. Для магазину окремо протестуйте вхід, додавання товару, оформлення замовлення та отримання підтвердження оплати в тестовому режимі.
Для звернення підготуйте приклади завислих дій, час збоїв, повідомлення хостингу та перелік недавніх змін. На сайті ремонту WordPress у Києві можна замовити діагностику черги PHP-запитів і відновлення динамічних функцій. Результат роботи варто приймати за відсутністю повторного збою та стабільним проходженням клієнтського сценарію.