Агенты Битрикс24: почему перенос на cron спасает портал

Один из самых распространённых запросов, с которыми к нам приходят владельцы коробочных порталов Битрикс24, звучит просто: «портал стал медленным». Первое, что мы проверяем в таких случаях, — раздел агентов. В девяти случаях из десяти именно они оказываются главным тормозом: тяжёлые агенты, выполняющиеся на каждом хите пользователя, превращают каждый клик в очередь из фоновых операций.

В этой статье разберём, как работают агенты Битрикс24, почему стандартный режим «на хитах» убивает производительность и как перенести их на cron без остановки портала. Материал основан на нашем опыте сопровождения коробочных установок — от 50 пользователей до порталов на несколько тысяч сотрудников.

Содержание

• Как работают агенты Битрикс24
• Почему агенты «на хитах» тормозят портал
• Перенос агентов на cron: пошаговый сценарий
• Границы, клапаны и очередь фоновых задач
• Логирование и мониторинг агентов
• Сравнение режимов выполнения
• Чек-лист безопасного переноса
• Вывод
• FAQ

Как работают агенты Битрикс24

Агент — это механизм ядра для отложенного и периодического выполнения PHP-кода: рассылка напоминаний, пересчёт индексов, синхронизация с внешними системами, генерация отчётов. Каждый агент — это запись в таблице b_agent с именем функции, параметрами и датой следующего запуска.

Есть два режима исполнения:

• На хитах (hit) — после отдачи страницы пользователю ядро выбирает из b_agent просроченные задачи и выполняет их «хвостом» ответа. Страница ушла клиенту, но PHP-процесс ещё занят.
• На cron — отдельный демон (в коробке это cron_events.php) раз в минуту запускает агентов вне веб-запросов. Хиты пользователей перестают нести фоновую нагрузку.

Ключевой нюанс, который часто упускают: даже один «тяжёлый» агент на хитах задерживает не только себя, но и всех остальных. Веб-процессы, занятые агентами, не обслуживают следующих посетителей — и при пиковой нагрузке начинается очередь соединений.

Классическая ошибка кастомной разработки — регистрировать агента на каждую мелкую задачу вместо одного обобщающего. Десятки агентов с интервалом «каждую минуту» создают постоянный фоновой шум: каждый цикл обхода таблицы b_agent сам по себе — запрос к базе, и он выполняется на каждом хите, даже когда очередь пуста.

Почему агенты «на хитах» тормозят портал

Механизм «на хитах» исторически выбран для удобства: агенты работают даже там, где нет доступа к cron (дешёвый shared-хостинг). Но на production-инсталляции он даёт три системные проблемы:

• Блокировка воркеров. PHP-FPM-процесс, выполняющий агент, недоступен для других запросов. На портале с 20 воркерами и агентом по 20 секунд каждый десятый хит занят фоновой работой.
• Непредсказуемые длительные запросы. Таймауты nginx и прокси (60 секунд по умолчанию) обрывают агента «на полпути». Вызов прерывается, но запись в b_agent уже обновлена — задача молча не выполняется до следующего цикла, а в логах появляются 499/504.
• Каскадные задержки. Агент, который не успел отработать, остаётся просроченным и догоняется на следующих хитах. Под нагрузкой это образует «шлейф», при котором каждый хит тащит фоновую очередь за собой.

В одном из наших проектов — портал дистрибьютора на 400 сотрудников — среднее время ответа в пике выросло до 4–6 секунд. После перевода агентов на cron и ревизии самих задач p95 отклика снизился до 0,8 секунды. Ни один запрос ядра при этом не менялся.

Перенос агентов на cron: пошаговый сценарий

Перенос — процедура низкорискованная, если следовать порядку. Полная остановка портала не требуется.

Шаг 1. Ревизия агентов

Выгрузите список: периодичность, время последнего и среднего выполнения (по данным таблицы b_agent), принадлежность (ядро / модули / кастом). Кандидаты на удаление — агенты отключённых модулей и «висящие» с давно удалённых решений Маркетплейса.

Шаг 2. Включаем cron-режим

В настройках главного модуля отключается запуск агентов на хитах, в crontab добавляется штатный обработчик:

# /etc/crontab или crontab -e для пользователя веб-сервера
*/1 * * * * www-data /usr/bin/php -f /var/www/bitrix/modules/main/tools/cron_events.php >/dev/null 2>&1

Обработчик запускается каждую минуту, но сам ядро честно отбирает только те агенты, срок которых подошёл — «лишний» запуск стоит дёшево.

Шаг 3. Проверяем критичные к минутам задачи

Рассылки, интеграции с внешними API, обмены с 1С — убедитесь, что минутной дискретизации хватает. Если какой-то агент должен срабатывать чаще, корректнее перевести его на собственный cron-скрипт в обход b_agent, а не сокращать интервал обработчика.

Шаг 4. Контрольная неделя

Первые 5–7 дней сравнивайте: время отклика хитов, длину очереди просроченных агентов, нагрузку PHP-FPM. Любые аномалии видны сразу, откат — один переключатель в настройках.

Если сопровождение портала вы делаете впервые или инфраструктура сложная (кластер, отдельная очередь задач), разумно заказать внедрение и аудит коробочного Битрикс24 — аудит агентов входит в наш стандартный чек-лист.

Границы, клапаны и очередь фоновых задач

Перенос на cron решает конфликт «фон против хитов», но не делает сами агенты быстрее. Дальше работают три приёма:

• Границы выполнения. Агент не должен обрабатывать «всё сразу»: разбивайте на порции (например, 500 элементов за запуск) и смещайте NEXT_EXEC. Тогда одна минута cron-цикла переваривает любой объём без роста пиковой нагрузки.
• Клапан параллелизма. Несколько тяжёлых агентов, попавших в один цикл, исполняются последовательно — и могут не уложиться в минуту. Длинные задачи выносите в отдельные cron-записи с распределением по минутам.
• Очередь вместо агента. Задачи со сложной логикой (массовые рассылки, интеграционные пакеты) лучше переводить на полноценную очередь — в нашей практике это Redis + Celery для смежных сервисов либо собственный воркер-процесс, вызывающий REST API портала. Агент остаётся тонким триггером: ставит задачу в очередь и завершается за миллисекунды.

Такой подход особенно важен в составе обмена Битрикс24 с 1С, где фоновая синхронизация документов и остатков — типовая нагрузка на агентов.

Логирование и мониторинг агентов

Без наблюдаемости агенты деградируют незаметно. Минимальный комплект, который мы ставим на все сопровождаемые порталы:

1. Лог длительности: каждый кастомный агент пишет время старта/финиша и количество обработанных элементов в отдельный файл или HL-блок.
2. Метрика «просроченность очереди»: раз в час сверяем NOW() с MAX(NEXT_EXEC) в b_agent; отставание больше 10 минут — алерт.
3. Замер «живости» cron: мониторинг факта запуска обработчика (строка в логе / heartbeat-файл с timestamp), чтобы отличить «агентов нет» от «cron не работает».
4. Еженедельный отчёт по топ-10 самых долгих агентов — основа для рефакторинга.

Для порталов с кастомной разработкой часть фоновых задач имеет смысл вынести в отдельные кастомные модули со своими cron-скриптами и журналами — так проще сопровождать и тестировать их изменения.

Сравнение режимов выполнения

Критерий	Агенты на хитах	Агенты на cron
Влияние на отклик страниц	Прямое: хиты тащат фоновую работу	Нулевое: фон отделён от веб-запросов
Риск обрыва длительных задач	Высокий (таймауты nginx/прокси)	Минимальный
Требование к хостингу	Нет (работает везде)	Нужен доступ к crontab
Дискретность запуска	Неуправляемая (по трафику)	Минимум раз в минуту, строго по расписанию
Наблюдаемость	Слабая, размазана по хитам	Полная: отдельный процесс, свои логи
Пригодность для production	Только мелкие порталы и dev	Стандарт для коробки

Чек-лист безопасного переноса

• Выгружен и разобран полный список агентов: владелец, периодичность, длительность.
• Удалены агенты отключённых модулей и решений.
• Тяжёлые агенты разбиты на порции со смещением NEXT_EXEC.
• Отключён запуск на хитах, добавлен cron_events.php в crontab от пользователя веб-сервера.
• Длительные задачи вынесены в отдельные cron-записи с равномерным распределением по минутам.
• Настроен heartbeat cron-обработчика и алерт на просроченную очередь.
• Кастомные агенты пишут логи старта/финиша и объёма работы.
• Проведена контрольная неделя: сравнены p95 отклика и нагрузка PHP-FPM до и после.

Вывод

• Агенты Битрикс24 — удобный механизм фоновых задач, но режим «на хитах» привязывает их исполнение к пользовательским запросам и превращается в главный источник тормозов коробки.
• Перенос на cron — стандартная обязательная настройка любого production-портала: она отделяет фон от веб-запросов и снимает риск обрыва задач таймаутами.
• Сам по себе перенос не ускоряет агенты: дальше нужны порционная обработка, отдельные cron-записи для тяжёлых задач и при необходимости внешняя очередь.
• Наблюдаемость — половина результата: без логов длительности и алертов на просрочку очереди агенты деградируют незаметно.

FAQ

Облачный Битрикс24 тоже страдает от агентов «на хитах»?

Нет: в облаке агентное обслуживание полностью на стороне вендора и не зависит от трафика вашего портала. Проблема актуальна только для коробочной версии, где вы управляете инфраструктурой сами.

Что делать, если у нас нет доступа к crontab?

Это повод сменить площадку или схему хостинга: внешний «cron через HTTP» — компромисс, он всё равно создаёт веб-запросы. Для коробки с кастомизацией нормальный доступ к планировщику — базовое требование к окружению.

Можно ли часть агентов оставить на хитах?

Технически — да, режимы можно комбинировать. Практической причины почти нет: всё, что должно работать «почти сразу», cron обеспечивает дискретностью в минуту. Исключение — очень маленькие порталы на слабом хостинге без shell-доступа.

Агент длится 10+ минут. Нормально ли это?

Для b_agent — плохой знак: задачу пора декомпозировать на порции или выносить в собственный воркер/очередь. Долгие монолитные агенты — первый кандидат в еженедельный рефакторинг по отчёту длительности.

Перенесли на cron, а портал всё равно медленный. Почему?

Смотрим дальше по чек-листу производительности: кеш, индексы MySQL, неоптимальные запросы. Часто корень проблем — в самих агентах, которые грузят базу. О типовых приёмах ускорения мы писали в статье «Оптимизация MySQL для Битрикс24: индексы, запросы и конфигурация».

Провести аудит агентов и перевести портал на cron без простоя можно силами нашей команды — напишите нам, вернём коробке скорость за одну итерацию.