Як усунути низьку продуктивність wp-admin/admin-ajax.php та високе завантаження процесора

Повільна адміністративна панель WordPress - одна з тих проблем, які можуть виникнути несподівано навіть на сайті, який раніше працював швидко. Сторінки /wp-admin/ починають відкриватися по кілька секунд, редактор зависає, збереження записів займає дуже багато часу, а в статистиці хостингу процесор періодично завантажується до 80-100%.

При аналізі логів у таких ситуаціях часто виявляється велика кількість запитів до /wp-admin/admin-ajax.php. Однак сам admin-ajax.php зазвичай не є джерелом проблеми. Це штатний AJAX-обробник WordPress, через який виконуються Heartbeat API, функції плагінів, фонові операції та інші динамічні завдання.

Тому головне завдання – не заблокувати admin-ajax.php, а визначити, який процес викликає його занадто часто або виконує надто важкі операції.

Коротка відповідь: якщо wp-admin працює повільно, а admin-ajax.php створює високе навантаження на CPU, спочатку знайдіть AJAX-дія (action), що генерує запити. Найчастіше причиною стають WordPress Heartbeat API, плагіни, WP-Cron або WooCommerce Action Scheduler. Обмежте зайві запити, оптимізуйте фонові завдання, базу даних та PHP, після чого повторно виміряйте навантаження.

Що таке admin-ajax.php і чому він з'являється у звітах про навантаження

admin-ajax.php - Системний файл WordPress, розташований за адресою:

/wp-admin/admin-ajax.php

Він приймає AJAX-запити та дозволяє браузеру взаємодіяти з WordPress без повного перезавантаження сторінки.

Наприклад, AJAX може використовуватися для:

• автоматичне збереження запису;
• блокування одночасного редагування;
• оновлення інформації в Dashboard;
• AJAX-пошуку;
• фільтрування товарів;
• відправлення форм;
• оновлення кошика;
• роботи деяких функцій WooCommerce;
• виконання фонових операцій плагінів;
• отримання повідомлень;
• динамічного завантаження даних.

Тому присутність admin-ajax.php в access log абсолютно нормальне явище.

Проблема починається тоді, коли запитів стає занадто багато або виконання одного запиту AJAX займає занадто багато процесорного часу.

Наприклад, один запит може займати лише 100-200 мс. Це майже непомітно.

Але якщо сайт одночасно генерує сотні таких запитів, PHP-процеси починають конкурувати за CPU, пам'ять та з'єднання з базою даних.

В результаті уповільнюється не тільки /wp-admin/, але іноді й публічна частина сайту

Основні причини високого навантаження admin-ajax.php

Універсальної причини немає. Насправді найчастіше зустрічається кілька сценаріїв.

WordPress Heartbeat API

Один із перших компонентів, який варто перевірити, — WordPress Heartbeat API.

Heartbeat — вбудований механізм WordPress, який періодично надсилає AJAX-запити між браузером та сервером.

Він необхідний для функцій, що працюють майже в реальному часі:

• автозбереження;
• контролю сесії;
• блокування запису при одночасному редагуванні;
• деяких оновлень адміністративної панелі;
• взаємодії окремих плагінів із сервером.

Запити Heartbeat виконуються періодично, тому одна відкрита адміністративна вкладка завжди підтримує зв'язок із сервером.

Якщо відкрито кілька вкладок або одночасно працюють кілька редакторів та адміністраторів, кількість запитів збільшується.

Чому Heartbeat здатний створювати високий CPU

Припустимо, Heartbeat виконується раз на 15-60 секунд.

Одна вкладка практично непомітна.

Але якщо одночасно відкриті:

• декілька вкладок редактора;
• WooCommerce Dashboard;
• адміністративні сторінки плагінів;
• панелі кількох співробітників,

кількість звернень до сервера швидко зростає.

Крім того, плагіни можуть підключати власні дії до Heartbeat. Тоді звичайний heartbeat-запит починає виконувати додатковий PHP-код та SQL-запити.

В результаті проблема полягає вже не так у частоті Heartbeat, як у вартості обробки кожного звернення.

Плагіни WordPress

Друга поширена причина – плагіни.

Багато розширень використовують власні AJAX-дії.

Особливо уважно варто перевірити:

• AJAX-фільтри;
• live search;
• статистику відвідувань;
• page builders;
• security-плагіни;
• системи повідомлень;
• чати;
• форми;
• імпорт та експорт;
• резервне копіювання;
• WooCommerce-розширення;
• плагіни синхронізації;
• Системи аналітики.

Погано оптимізований плагін може надсилати запит при кожному перегляді сторінки або повторювати кожні кілька секунд.

На сайті з невеликою відвідуваністю це залишиться непомітним. За кілька тисяч відвідувачів кількість звернень до PHP може стати величезною.

WP-Cron

WP-Cron – вбудований механізм WordPress для виконання запланованих завдань.

Через нього можуть виконуватися:

• публікація відкладених записів;
• автоматичні поновлення;
• очищення тимчасових даних;
• відправлення листів;
• резервне копіювання;
• синхронізація;
• завдання WooCommerce;
• завдання сторонніх плагінів.

WP-Cron відрізняється від класичного системного cron.

WordPress перевіряє наявність запланованих подій у процесі обробки запитів та за потреби ініціює їх виконання.

Сам собою цей механізм нормально працює на більшості невеликих сайтів. Проблеми виникають, коли завдань стає багато чи окремі завдання виявляються надто важкими.

Наприклад, один плагін може створювати cron-завдання щохвилини, яка виконує десятки SQL-запитів.

В результаті навантаження від AJAX та cron накладається один на одного.

WooCommerce та Action Scheduler

На WooCommerce-сайтах необхідно окремо перевіряти Action Scheduler.

Це система черг фонових завдань, яку WooCommerce та різні розширення використовують для:

• обробки платежів;
• webhooks;
• відправлення листів;
• синхронізації;
• обробки передплат;
• імпорту;
• виконання відстрочених дій.

Сама наявність Scheduled Actions є нормальною.

Проблема виникає, якщо черга починає зростати швидше, ніж сервер здатний її обробляти.

Наприклад:

• тисячі Pending actions;
• велика кількість Failed actions;
• що зависли In-progress actions;
• один і той же hook створюється знову і знову.

У такому разі CPU може залишатися високим навіть за порівняно невеликої відвідуваності сайту.

Повільні SQL-запити

Іноді admin-ajax.php лише допомагає виявити зовсім іншу проблему.

Типовий ланцюжок виглядає так:

admin-ajax.php → плагин → SQL-запрос → MySQL → высокий CPU

Якщо один AJAX-запит виконує важкий SQL-запит у таблиці з мільйонами записів, навіть невелика кількість AJAX-дзвінків здатна помітно уповільнити сайт.

Особливо уважно слід перевіряти:

• wp_options;
• wp_postmeta;
• WooCommerce-таблиці;
• таблиці Action Scheduler;
• власні таблиці плагінів;
• таблиці статистики та логування.

Занадто великий autoload в wp_options

WordPress автоматично завантажує певні записи з таблиці wp_options.

Якщо плагіни накопичили занадто великий обсяг даних, що автоматично завантажуються, кожен динамічний запит WordPress стає важче.

Це стосується і admin-ajax.php.

Виходить неприємна комбінація:

багато AJAX-запитів + ​​великий autoload + повільна база даних = високе навантаження CPU.

Тому при серйозній діагностиці WordPress необхідно перевіряти як кількість AJAX-запитів, а й стан бази даних.

Як визначити, що саме викликає admin-ajax.php

Найважливіший етап оптимізації – визначити джерело запитів.

Просто побачити /wp-admin/admin-ajax.php у логах недостатньо.

Перевіряємо запити через Chrome DevTools

Відкрийте проблемну сторінку WordPress та натисніть:

F12 → Network → Fetch/XHR

Після цього спостерігайте запити протягом однієї-двох хвилин.

Якщо регулярно з'являється:

/wp-admin/admin-ajax.php

відкрийте запит та вивчіть його параметри.

Особливу увагу приділіть параметру:

action

Наприклад:

action=heartbeat

означає, що запит відноситься до Heartbeat API.

У стороннього плагіна значення може виглядати зовсім інакше:

action=plugin_name_some_action

Назва action часто одразу вказує на джерело проблеми.

Чому параметр action такий важливий

WordPress використовує динамічний AJAX hooks.

Для авторизованих користувачів вони мають вигляд:

wp_ajax_{action}

Для неавторизованих:

wp_ajax_nopriv_{action}

Тому, якщо ви виявили невідомий action, виконайте пошук відповідного рядка в:

/wp-content/plugins/

і:

/wp-content/themes/

Часто в такий спосіб можна за кілька хвилин визначити плагін або тему, яка зареєструвала проблемну AJAX-дію.

Аналізуємо access log сервера

DevTools показує запити лише вашого браузера.

Для картини необхідно вивчити серверний access log.

Знайдіть звернення до:

/wp-admin/admin-ajax.php

Після цього оцініть:

• кількість запитів;
• частоту;
• IP-адреси;
• User-Agent;
• метод запиту;
• час виконання;
• AJAX action.

Особливо підозріла ситуація, коли одна дія виконується сотні чи тисячі разів за короткий період.

Як зменшити навантаження WordPress Heartbeat

Якщо з'ясувалося, що більшість запитів створює action=heartbeatможна оптимізувати частоту Heartbeat.

Чи потрібно повністю відключати Heartbeat

Зазвичай ні.

Повне відключення здатне порушити:

• автозбереження;
• блокування записів;
• попередження про одночасне редагування;
• функції деяких плагінів.

Більш безпечна стратегія – регулювати Heartbeat залежно від області сайту.

Наприклад:

Frontend: вимкнути, якщо він там справді не використовується.

Dashboard: збільшити проміжок часу.

Редактор записів: залишити увімкненим.

Так можна зменшити кількість звернень до admin-ajax.php, зберігаючи корисні функції WordPress.

Не забувайте про декілька відкритих вкладок

Дуже простий, але часто ігнорований фактор – кількість відкритих вкладок браузера.

Якщо редактор або адміністратор залишив відкритими кілька сторінок /wp-admin/Кожна з них потенційно продовжує виконувати фонові запити.

Працюючи команди з кількох людина навантаження множиться.

Тому при діагностиці варто перевірити ситуацію не тільки в режимі «один користувач — одна вкладка», а й за умов реальної роботи редакції чи інтернет-магазину.

Читайте також:
Чим плагін Clearfy Pro корисний для сайтів WordPress

Як перевірити плагіни на надмірне AJAX-навантаження

Якщо Heartbeat оптимізовано, але проблема залишилася, переходьте до плагінів.

Знайдіть власника AJAX action

Допустимо, DevTools показує:

action=my_plugin_refresh

Виконайте пошук:

my_plugin_refresh

за каталогом:

wp-content/plugins

З високою ймовірністю ви знайдете розширення, яке реєструє цю дію.

Після цього необхідно зрозуміти:

1. Чому запит виконується?
2. Як часто він виконується?
3. Чи потрібна ця функція?
4. Чи можна зменшити частоту?
5. Чи можна вимкнути конкретну функцію плагіна?
6. Чи існує продуктивніша альтернатива?

Відключайте плагіни лише на staging

Для діагностики можна тимчасово відключати підозрілі плагіни та вимірювати зміну навантаження.

Однак на робочому WooCommerce-сайті подібні експерименти є небезпечними.

Краще створити staging-копію та проводити тести там.

Після відключення кожного підозрілого розширення порівнюйте:

• ЦП;
• ОЗП;
• PHP workers;
• TTFB;
• кількість запитів до admin-ajax.php;
• час відповіді AJAX.

Важливо вимірювати показники, а не орієнтуватися виключно на суб'єктивне відчуття «стало швидше».

Як оптимізувати WP-Cron

Якщо веб-сайт виконує багато фонових завдань, варто перевірити WP-Cron.

Перегляд cron-задач

За наявності WP-CLI використовуйте:

wp cron event list

Подивіться:

• які hooks існують;
• як часто вони запускаються;
• чи є прострочені події;
• чи існують завдання віддалених плагінів;
• чи немає підозріло частих завдань.

Якщо невідомий hook виконується щохвилини, з'ясуйте, який плагін його зареєстрував.

Переклад WP-Cron на системний cron

Для відвідуваних сайтів та WooCommerce-магазинів можна розглянути запуск cron через системний планувальник сервера.

В wp-config.php стандартний запуск WP-Cron вимикається:

define( 'DISABLE_WP_CRON', true );

Після цього необхідно створити справжнє cron-завдання на сервері, наприклад, із запуском кожні 5 хвилин.

Так виконання фонових завдань стає більш передбачуваним і менше залежить від вхідного трафіку.

Важливо: не можна просто встановити DISABLE_WP_CRON і нічого не робити.

Інакше WordPress перестане своєчасно виконувати заплановані завдання.

Як перевірити WooCommerce Action Scheduler

Якщо встановлено WooCommerce, відкрийте:

WooCommerce → Status → Scheduled Actions

Деякі конфігурації Scheduled Actions також доступні через меню інструментів WordPress.

Які статуси потрібно перевірити

Зверніть увагу на:

Pending - очікування виконання завдання.

Failed - завдання, що завершилися помилкою.

In-progress - завдання, що виконуються.

Наявність кількох завдань – нормальна.

Але якщо ви бачите тисячі чи десятки тисяч Pending/Failed actions, необхідно знайти джерело.

Не видаляйте чергу без з'ясування причини

Припустимо, плагін щохвилини створює 100 нових завдань.

Можна видалити 10000 Pending actions.

За кілька годин черга з'явиться знову.

Тому необхідно визначити:

який hook створює завдання → який плагін йому належить → чому черга зростає.

Тільки після цього має сенс очищати завдання, що накопичилися.

Оптимізація бази даних WordPress

Якщо AJAX-запитів небагато, але кожен виконується довго, проблема може бути у MySQL/MariaDB.

Використовуйте Slow Query Log

MySQL Slow Query Log дозволяє виявити запити, виконання яких займає багато часу.

Особливо корисно зіставляти час SQL-запитів із сплесками CPU.

Наприклад:

admin-ajax.php → plugin callback → SELECT ... → 4,2 секунды

Такий результат вже практично вказує на причину.

Перевірте wp_options та autoload

Великий обсяг autoload-даних збільшує вартість багатьох динамічних запитів WordPress.

Причиною часто стають:

• віддалені плагіни;
• кешовані налаштування;
• транзієнти;
• плагіни статистики;
• старі інтеграції.

Але не видаляйте рядки з wp_options тільки тому, що вони виглядають більшими.

Спочатку створіть резервну копію та визначте, якому компоненту належить кожен запис.

Перевірте таблиці плагінів

Деякі плагіни роками накопичують:

• логі;
• статистику;
• історію дій;
• сесії;
• події;
• черги.

Таблиця може зрости до мільйонів рядків, після чого запит, який раніше виконувався за 20 мс, починає тривати секунди.

У разі потрібно непросто «оптимізація бази», а аналіз конкретних запитів і індексів.

Redis та Persistent Object Cache

Для динамічних WordPress-сайтів корисний Persistent Object Cache.

Найчастіше для цього застосовується Redis.

Він може зменшити кількість повторних запитів до бази даних і особливо корисний для:

• WooCommerce;
• membership-сайтів;
• великих каталогів;
• сайтів із безліччю авторизованих користувачів;
• проектів з активно використовуваним /wp-admin/.

Але важливо розуміти призначення Redis.

Якщо плагін надсилає тисячі непотрібних AJAX-запитів, Redis не усуне причини.

Правильний порядок:

спочатку прибрати зайві запити → потім оптимізувати виконання тих, що залишилися.

PHP-FPM, OPcache та серверні ресурси

Після оптимізації WordPress можна перевірити серверну конфігурацію.

PHP-FPM

Зверніть увагу на:

• кількість PHP workers;
• ліміти пам'яті;
• максимальна кількість процесів;
• час виконання запитів;
• PHP-FPM slow log.

Якщо всі workers зайняті довгими AJAX-запитами, нові запити чекатимуть на звільнення процесів.

Користувач при цьому побачить повільний сайт.

OPcache

На production-сервері PHP OPcache зазвичай має бути включений.

Без нього PHP доводиться частіше заново компілювати PHP-файли в байт-код, що створює непотрібне навантаження.

На WordPress із десятками плагінів це особливо помітно.

Чи завжди потрібно збільшувати CPU

Ні.

Припустимо, плагін генерує 50 непотрібних AJAX-запитів на секунду.

Перехід із 2 CPU на 4 CPU дійсно може тимчасово покращити ситуацію.

Але хибний процес продовжить працювати.

За деякий час навантаження знову стане проблемою.

Тому масштабування сервера має відбуватися після програмної оптимізації , а чи не замість неї.

Що робити, якщо гальмує лише wp-admin

Поширена ситуація:

• головна сторінка відкривається за 0,5 секунд;
• /wp-admin/ - За 5-10 секунд.

Це цілком можливо.

Публічна частина сайту може обслуговуватись з page cache, тоді як адміністративна панель залишається динамічною.

Кожне відкриття сторінки /wp-admin/ може запускати:

• WordPress Core;
• активні плагіни;
• SQL-запити;
• перевірки оновлень;
• зовнішні API;
• адміністративні повідомлення;
• WooCommerce;
• фонові процеси.

Тому висока швидкість frontend ще не означає, що WordPress оптимізовано.

Що перевіряти насамперед

Якщо гальмує саме /wp-admin/, зверніть особливу увагу на:

1. плагіни;
2. повільні SQL-запити;
3. Heartbeat;
4. зовнішні HTTP-запити;
5. WooCommerce Scheduled Actions;
6. WP-Cron;
7. autoload;
8. PHP workers.

Встановлення ще одного cache-плагіну в такій ситуації далеко не завжди допоможе.

Що робити, якщо admin-ajax.php навантажує публічну частину сайту

Серйозніша ситуація виникає, коли AJAX-запити масово відправляють звичайні відвідувачі.

Допустимо, плагін виконує один AJAX-запит при кожному перегляді сторінки.

При 10 000 переглядів отримуємо ще:

10 000 PHP-запитів до admin-ajax.php.

Якщо кожен запит виконує п'ять SQL запитів, сервер додатково отримує до 50 000 звернень до бази даних.

Як оптимізувати такий сценарій

Поставте кілька запитань:

• чи дійсно AJAX потрібен для кожного перегляду сторінки;
• чи можна виконувати запит лише після дії користувача;
• чи можна кешувати відповідь;
• чи можна збільшити інтервал;
• чи можна поєднати кілька запитів;
• чи можна перенести частину логіки на клієнт;
• чи можна замінити механізм ефективнішою реалізацією.

Для сайту, що високо відвідувається, навіть невелика оптимізація частоти AJAX може дати істотне зниження навантаження.

Чи може причиною бути бот чи атака

Так. Не всі звернення до admin-ajax.php обов'язково створюються реальними відвідувачами.

перевірте:

• IP-адреса;
• User-Agent;
• частоту;
• referrer;
• AJAX action;
• POST payload;
• характер інтервалів.

Якщо один IP надсилає сотні однакових запитів на хвилину, це може бути бот або автоматизований скрипт.

Коли використовувати WAF та Rate Limiting

Для обмеження небажаного трафіку можна використати:

• Cloudflare WAF;
• Rate Limiting;
• Nginx;
• ModSecurity;
• засоби захисту хостингу.

Але правило має бути максимально точним.

Не варто блокувати весь:

/wp-admin/admin-ajax.php

через одну проблемну дію.

Чому не можна просто заблокувати admin-ajax.php

Це одна з найнебезпечніших «оптимізацій».

Повне блокування файлу може порушити:

• адміністративну панель;
• автозбереження;
• WooCommerce;
• AJAX-фільтри;
• форми;
• пошук;
• плагіни;
• динамічні функції сайту

Тобто навантаження справді зникне — разом із частиною функціональності сайту.

Набагато правильніше визначити конкретний action та працювати саме з ним.

Інструменти для пошуку причини високого навантаження

Для професійної діагностики бажано використовувати кілька інструментів.

Інструменти розробника Chrome

Показує AJAX-запити браузера та дозволяє визначити їх частоту та параметри.

Монітор запитів

Корисний для аналізу:

• SQL;
• гачки;
• HTTP API;
• PHP-помилок;
• компонентів, що виконуються під час завантаження WordPress.

WP-CLI

Дозволяє швидко працювати з WordPress з командного рядка, включаючи cron-завдання та базу даних.

PHP-FPM Slow Log

Допомагає виявляти PHP-процеси, які виконуються надто довго.

Журнал повільних запитів MySQL

Показує повільні SQL-запити.

APM

На великих проектах можна використовувати New Relic та інші APM-системи.

Вони допомагають побачити ланцюжок:

HTTP request → PHP function → plugin → SQL → зовнішній API.

Це прискорює пошук вузького місця.

Покроковий алгоритм діагностики admin-ajax.php

Якщо потрібно знайти проблему максимально швидко, використовуйте таку послідовність.

Крок 1. Зафіксуйте вихідні показники

Запишіть:

• ЦП;
• ОЗП;
• load average;
• кількість PHP workers;
• TTFB;
• час відповіді /wp-admin/.

Це дозволить зрозуміти, чи справді подальші зміни допомогли.

Крок 2. Перевірте access log

Знайдіть:

/wp-admin/admin-ajax.php

Подивіться, як часто він викликається.

Крок 3. Визначте action

Через DevTools або логи з'ясуйте значення:

action=...

Це один із найважливіших етапів.

Крок 4. Перевірте Heartbeat

Якщо використовується:

action=heartbeat

перегляньте частоту запитів та кількість одночасно відкритих адміністративних сторінок.

Крок 5. Знайдіть проблемний плагін

Якщо action належить сторонньому розширенню, визначте його за вихідним кодом.

Крок 6. Перевірте WP-Cron

Перегляньте список подій та частоту їх виконання.

Крок 7. Перевірте Action Scheduler

Для WooCommerce обов'язково вивчіть Pending, Failed та In-progress actions.

Крок 8. Перевірте базу даних

Використовуйте Slow Query Log та проаналізуйте wp_options, autoload та великі таблиці.

Крок 9. Перевірте PHP

Вивчіть PHP-FPM workers, slow log, memory limit та OPcache.

Крок 10. Повторіть виміри

Після кожної істотної зміни порівнюйте результати з вихідними показниками.

Саме останній крок часто забувають.

Без вимірів неможливо точно визначити, чи справді оптимізація вирішила проблему.

Часті помилки під час усунення високого навантаження

Спроба максимально швидко знизити CPU іноді призводить до ще більших проблем.

Повне відключення Heartbeat

Може порушити автозбереження та інші функції WordPress.

Найкраще регулювати частоту.

Блокування admin-ajax.php

Може вивести з ладу безліч функцій сайту.

Видалення всіх Cron Events

Частина плагінів перестане виконувати необхідні фонові операції.

Масове очищення wp_options

Можна видалити критично важливі параметри.

Очищення Action Scheduler без пошуку причин

Черга знову заповниться, якщо плагін продовжує створювати завдання.

Негайне збільшення потужності VPS

Допомагає лише тоді, коли серверу справді не вистачає ресурсів після оптимізації програми.

Встановлення кількох оптимізаторів

Декілька cache/optimization-плагінів здатні конфліктувати один з одним і зробити діагностику ще складніше.

Як зрозуміти, що проблема справді усунена

Не обмежуйтеся тим, що адміністративна панель суб'єктивно почала працювати швидше.

Після оптимізації порівняйте:

• середній CPU;
• піки CPU;
• ОЗП;
• load average;
• кількість admin-ajax.php запитів;
• середній час AJAX-відповіді;
• TTFB;
• PHP worker utilization;
• кількість повільних SQL-запитів;
• розмір черги Scheduled Actions.

Краще порівнювати однакові періоди.

Наприклад:

24 години до оптимізації → 24 години після оптимізації.

Так результат буде значно об'єктивнішим.

Питання та відповіді

Високе навантаження від /wp-admin/admin-ajax.php - Найчастіше симптом, а не самостійна проблема.

Найпоширеніша помилка – побачити admin-ajax.php у звіті хостингу і одразу спробувати відключити Heartbeat, заблокувати AJAX або збільшити потужність сервера.

Професійна діагностика будується інакше:

визначити запит → знайти action → встановити джерело → виміряти частоту → перевірити PHP/SQL, що виконується → усунути причину → повторно виміряти навантаження.

Насамперед варто перевірити WordPress Heartbeat API, плагіни, WP-Cron та WooCommerce Action Scheduler. Якщо з кількістю запитів все нормально, наступний рівень діагностики – база даних, autoload, PHP-FPM, зовнішні API та серверна конфігурація.

І головне правило при роботі з admin-ajax.php:

не блокуйте механізм повністю - знайдіть конкретний процес, який використовує його неефективно.

Такий підхід дозволяє не лише знизити завантаження CPU, а й помітно прискорити /wp-admin/, скоротити час AJAX-відповідей та підвищити стабільність WordPress під навантаженням.

Джерела

1. FluxPress — admin-ajax.php High CPU в WordPress: Heartbeat & Cron Explained. Матеріал про високе навантаження admin-ajax.php, Heartbeat API та WP-Cron.
2. WordPress Developer Resources - Heartbeat API. Офіційна документація WordPress про механізм Heartbeat, його AJAX-запити та інтервали роботи.
3. WordPress Developer Resources - wp_ajax_heartbeat(). Офіційна документація серверного обробника Heartbeat.
4. WordPress Developer Resources - wp_ajax_{$action}. Офіційна документація динамічних AJAX hooks та параметра action.
5. WordPress Developer Resources - _wp_cron(). Документація внутрішнього механізму опрацювання запланованих подій WordPress.
6. WordPress Advanced Administration Handbook – wp-config.php. Офіційна документація констант DISABLE_WP_CRON, ALTERNATE_WP_CRON та інших параметрів конфігурації WordPress.
7. Action Scheduler – офіційна документація. Документація системи фонових черг, що використовується WooCommerce та іншими WordPress-плагінами.
8. Action Scheduler - Scheduled Actions Administration Screen. Документація з перегляду Pending, Failed, In-progress та інших фонових завдань.

Олексій Шевченко

редактор wpcafe

Вивчає сайтобудування з 2008 року. Практикуючий вебмайстер, що спеціалізується на створенні сайтів WordPress. Задати питання Олексію можна на https://profiles.wordpress.org/wpthemeus/