Налаштування cron для агентів 1С-Бітрікс: прискорення сайту
Чому агенти на хітах — вузьке місце?
Уявіть: інтернет-магазин будматеріалів з каталогом на 200 000 товарів. У непикові години сторінки відкриваються за секунду, але вдень 10% запитів гальмують до 8 секунд. Причина — агенти Бітрікса, що працюють у режимі «на хітах». Кожен HTTP-запит перевіряє таблицю b_agent, і якщо настав час виконання — агент запускається синхронно, змушуючи користувача чекати. При піковому навантаженні (100+ одночасних користувачів) це може викликати ефект «каскадного гальмування»: час відповіді зростає експоненційно, а серверне навантаження збільшується в 2–3 рази.
Ми — сертифіковані фахівці з 5+ роками досвіду оптимізації 1С-Бітрікс, виконали понад 50 успішних проектів. Гарантуємо якість робіт. Допомагаємо перевести агенти 1С-Бітрікс на cron — це перенесення виконання фонових завдань з HTTP-запитів в окремий процес за розкладом. Результат: стабільна швидкість сайту незалежно від трафіку та економія серверних ресурсів за рахунок зниження пікових навантажень. Зв'яжіться з нами для діагностики поточного стану — оцінимо ситуацію за один день.
Три проблеми режиму «на хітах»
- Непередбачуваність. Агент з періодом 300 секунд запускається тільки коли прийде наступний відвідувач. Вночі, при низькому трафіку, виконання може відкластися на години. Це особливо критично для завдань синхронізації з 1С та надсилання сповіщень.
- Уповільнення сторінок. Важкий агент (синхронізація з 1С, надсилання листів) виконується прямо під час запиту, збільшуючи час відповіді для конкретного користувача. За даними досліджень, втрата конверсії до 7% на кожну секунду затримки.
-
Обмеження за часом.
max_execution_time(зазвичай 30–60 секунд) може перервати агент, залишивши завдання незавершеним. Це призводить до дублювання даних і помилок.
Переваги cron: таблиця порівняння
| Критерій | На хітах | Через cron |
|---|---|---|
| Час виконання | В момент запиту | Фоново, за розкладом |
| Передбачуваність | Залежить від трафіку | Завжди строго за інтервалом (cron краще в 10 разів) |
| Вплив на користувачів | Прямий (гальмування) | Відсутній |
| Управління навантаженням | Неможливо | Налаштовується інтервал і блокування |
| Максимальний час | Обмежено PHP | Не обмежено (можна set_time_limit(0)) |
Типові помилки при переведенні на cron
| Помилка | Наслідки | Рішення |
|---|---|---|
| Невірний шлях до PHP | Агенти не запускаються | Використовувати which php |
| Відсутність блокувань | Паралельні запуски — дублювання даних | Додати flock в crontab |
| Ігнорування критичних агентів | Збій важливих бізнес-процесів | Перевірити кожен агент окремо |
Як перевести агенти на cron правильно?
Крок 1. Перевірка поточного режиму
В адмінці: «Налаштування → Налаштування модулів → Головний модуль». Параметр «Використання агентів» — якщо стоїть «У режимі хітів», потрібен переклад. Також можна виконати SQL-запит: SELECT NAME, LAST_EXEC, NEXT_EXEC FROM b_agent WHERE ACTIVE='Y' ORDER BY LAST_EXEC DESC LIMIT 20; — якщо NEXT_EXEC відстає від LAST_EXEC більше ніж на годину, це опосередкована ознака проблеми.
Крок 2. Налаштування crontab
Підключіться до сервера по SSH і відкрийте crontab:
crontab -e -u bitrix Додайте рядки:
# Агенти Бітрікс — кожну хвилину * * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1 # Черга поштових подій — кожні 5 хвилин */5 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/event_exec.php > /dev/null 2>&1 Перевірте шлях до PHP через which php. Для захисту від паралельних процесів додайте flock:
* * * * * /usr/bin/flock -n /tmp/bitrix_cron.lock /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1 Крок 3. Перемикання режиму в Бітріксі
Після налаштування cron і перевірки (запустіть скрипт вручну: /usr/bin/php -f /path/to/cron_events.php) — перемкніть опцію на «Через cron» і збережіть. Очистіть кеш платформи. Рекомендується спочатку перевести тестову копію сайту.
Крок 4. Перевірка виконання
Виконайте SQL-запит:
SELECT NAME, LAST_EXEC, NEXT_EXEC FROM b_agent WHERE ACTIVE='Y' ORDER BY LAST_EXEC DESC LIMIT 20; LAST_EXEC повинен оновлюватися кожну хвилину. Якщо ні — перевірте системний лог cron (/var/log/cron) і виведення помилок PHP. Також налаштуйте моніторинг — наприклад, надсилайте алерт в Telegram якщо агент не виконувався більше 5 хвилин.
Чому cron економить ресурси сервера?
При роботі на хітах кожен запит навантажує сервер викликом CAgent::CheckAgents(). На слабких конфігураціях (1–2 ядра) це може займати до 200–300 мс на запит, що при 1000 запитів на годину дає додаткове навантаження в 50–80 секунд процесорного часу на годину. Cron прибирає це навантаження повністю, а фоновий процес виконується 1–2 секунди на хвилину.
Кейси з нашої практики
Приклад 1: Зниження часу відповіді на 90%
Наш клієнт — великий онлайн-магазин будматеріалів. Скарги на «випадкові» гальмування до 5–10 секунд. Профайлер показав: у 10% запитів CAgent::CheckAgents() додавав 3–8 секунд через агента переіндексації пошуку та обробки черги сповіщень.
Після переведення всіх агентів на cron:
-
CAgent::CheckAgents()зник із профайлера. - 99-й перцентиль часу відповіді знизився з 8,2 до 0,9 секунди.
- Агенти переіндексації стали працювати раз на хвилину непомітно для користувачів.
- Економія серверних ресурсів склала значну суму.
Приклад 2: Нічна синхронізація з 1С
Наш клієнт — інтернет-магазин побутової техніки. Агент синхронізації залишків з періодом 3600 секунд виконувався нерегулярно, вночі залишки не оновлювалися до ранку. Причина — режим «на хітах» і низький нічний трафік.
Ми перевели агенти на cron із запуском кожну хвилину. Агент синхронізації став виконуватися строго за розкладом. Додатково виявили, що агент іноді перевищував max_execution_time — додали set_time_limit(0) на початку скрипта. Тепер залишки оновлюються кожні 60 хвилин цілодобово.
Що входить в роботу
- Діагностика поточного режиму агентів та їх впливу на продуктивність.
- Налаштування crontab з блокуваннями від паралельних запусків.
- Перемикання режиму в Бітріксі та очистка кешу.
- Тестування кожного критичного агента (сповіщення, вивантаження, індексація).
- Налаштування моніторингу виконання з алертами при збоях.
- Документація з обслуговування та відновлення.
- Рекомендації щодо подальшої оптимізації (кешування, відкладені функції).
Терміни та як замовити
Базове налаштування займає 4–8 годин. Якщо потрібна комплексна діагностика та оптимізація повільних агентів — 1–3 робочих дні.
Отримайте консультацію: зв'яжіться з нами, і ми запропонуємо план робіт під ваш проект. Оцініть продуктивність вашого сайту — це безкоштовно.