Настройка отложенных функций (deferred functions) 1С-Битрикс

Пользователь нажимает «Оформить заказ» и видит спиннер 4 секунды — сервер синхронно отправляет три письма, пересчитывает бонусы, дёргает API доставки. Время простоя растёт, конверсия падает. Мы сталкиваемся с этим на каждом втором проекте с высокой нагрузкой. Deferred functions решают проблему: HTTP-ответ возвращается за 200 мс, а тяжёлые операции выполняются фоново, после закрытия соединения. Это снижает нагрузку на сервер и повышает удовлетворённость пользователей.

Какие проблемы решают deferred functions?

Синхронная обработка всех действий в запросе приводит к избыточному времени ожидания для клиента. Типичные операции, которые можно вынести: отправка email/SMS (200–500 мс), логирование в ELK или Sentry, инвалидация тегированного кеша, вызовы внешних API (CRM, службы доставки). Каждая такая операция увеличивает время ответа, а их сумма может достигать нескольких секунд. Deferred functions изолируют эти задачи, возвращая управление пользователю мгновенно.

Как работают deferred functions?

Начиная с актуальных версий PHP, ядро Битрикс поддерживает register_shutdown_function и собственный механизм через Bitrix\Main\Application::getInstance()->addBackgroundJob(). Суть: функция регистрируется и выполняется после fastcgi_finish_request() (для PHP-FPM) или после отправки ответа для Apache mod_php через register_shutdown_function. Разница критична: на PHP-FPM соединение сбрасывается до выполнения задачи, на mod_php — нет.

use Bitrix\Main\Application; Application::getInstance()->addBackgroundJob(function () { // Код выполнится ПОСЛЕ отправки ответа клиенту \Bitrix\Main\Mail\Event::send([...]); // Логирование, вызов API, пересчёт данных }); 

Критический нюанс: addBackgroundJob работает только при наличии fastcgi_finish_request. Проверяйте: function_exists('fastcgi_finish_request'). На Apache mod_php функция выполнится до отправки ответа.

Пошаговая настройка deferred functions

1. Проверьте окружение. Выполните phpinfo() и найдите fastcgi_finish_request в разделе PHP-FPM. Если функция отсутствует, переключитесь на PHP-FPM или используйте cron.
2. Определите тяжёлые операции. Профилируйте страницы с помощью встроенного профайлера Битрикс. Выявите блоки, которые занимают более 100 мс: отправка писем, логирование, вызовы API.
3. Оберните их в addBackgroundJob. Для каждого обработчика события (например, OnSaleOrderSaved) замените синхронный вызов на фоновый.
4. Настройте таймауты. В конфигурации пула PHP-FPM установите request_terminate_timeout=300, чтобы фоновые задачи не обрывались.
5. Протестируйте. Замерьте время ответа до и после. Сравните с помощью ab или JMeter.

Для гарантированного выполнения на PHP-FPM также проверьте max_execution_time в php.ini — он должен быть не меньше. Рекомендуется мониторить логи на предмет преждевременных завершений.

Почему deferred functions лучше синхронной обработки?

Deferred functions сокращают время ответа пользователя в 3–5 раз. В одном проекте мы вынесли из синхронного потока отправку трёх писем и логирование — время выполнения заказа упало с 4,5 секунд до 0,3 секунды. Это напрямую влияет на конверсию: каждые 100 мс задержки снижают конверсию на 1%. Экономия на серверных мощностях достигает 40%.

Deferred functions выигрывают по скорости внедрения и минимальной нагрузке на инфраструктуру. Если задача критична — используйте очередь.

Когда стоит использовать deferred functions?

• Отправка email/SMS после оформления заказа — задержка 200–500 мс на каждое письмо
• Логирование в файл или внешний сервис (ELK, Sentry)
• Инвалидация тегированного кеша после обновления каталога
• Вызовы внешних API: уведомление CRM, обновление складского сервиса
• Переиндексация элемента после изменения

Типичные ошибки при настройке

• Использование deferred functions на Apache mod_php без проверки fastcgi_finish_request — функция выполняется синхронно.
• Слишком короткий request_terminate_timeout — фоновые задачи не успевают завершиться.
• Отсутствие обработки ошибок внутри addBackgroundJob — исключение может упасть вне контекста и не быть залогировано.
• Вынос критических операций (например, фискализация) без fallback — при сбое данные потеряются.

Пример из практики

На проекте интернет-магазина с 50 000 заказов в месяц мы вынесли в отложенные функции отправку писем (3 письма на заказ), логирование и вызов API СДЭК. Время ответа на странице оформления заказа снизилось с 4,5 секунд до 0,3 секунды. Нагрузка на сервер упала на 40%, что позволило отказаться от дополнительной ноды. Окупаемость внедрения составила менее недели за счёт снижения нагрузки.

Что входит в настройку

• Проверка совместимости серверного окружения (PHP-FPM, fastcgi_finish_request)
• Вынос тяжёлых обработчиков событий в addBackgroundJob
• Настройка request_terminate_timeout в PHP-FPM
• Мониторинг: логирование времени выполнения фоновых задач
• Тестирование: замер времени ответа до и после переноса операций в отложенные функции

Как мы помогаем

Мы внедрили отложенные функции на 30+ проектах. Инженеры знают все тонкости fastcgi_finish_request и настройки PHP-FPM. Предоставляем документацию и поддержку после внедрения. Получите консультацию — оценим ваш проект за 1 день. Свяжитесь с нами, чтобы узнать, подходит ли ваш сайт для этой оптимизации.

Согласно официальной документации PHP, fastcgi_finish_request доступен только при использовании FastCGI Process Manager. fastcgi_finish_request

Дополнительно: ознакомьтесь с документацией addBackgroundJob на официальном портале 1С-Битрикс.