В процессе эксплуатации высоконагруженных систем на платформе 1С:Предприятие 8.3 часто возникает специфическая проблема: между вызовом метода ФоновыеЗадания.Выполнить() и фактическим началом исполнения программного кода в процедуре проходит значительное время (в некоторых случаях — более 10–15 секунд). Это особенно критично для формирования отчетов в интерактивном режиме, таких как Оборотно-сальдовая ведомость, когда пользователь ожидает немедленной реакции системы.
Разберем подробно причины такой задержки и проанализируем шаги, которые помогут ускорить старт фоновых процессов в клиент-серверном варианте работы.
Рассмотрим наиболее вероятную причину задержки, которая часто встречается при администрировании кластера 1С. В консоли администрирования серверов 1С (MMC) в свойствах рабочего сервера существует параметр Количество соединений на рабочий процесс.
Проанализируем ситуацию: если этот параметр установлен в значение 1, это означает, что каждый новый сеанс (включая сеанс фонового задания) вынуждает систему запускать отдельный процесс rphost.exe. Запуск нового процесса в операционной системе — это ресурсозатратная операция, включающая выделение оперативной памяти, инициализацию программных модулей и загрузку контекста конфигурации.
Рекомендация: Увеличьте значение этого параметра. По умолчанию рекомендуется устанавливать значение 128 или выше, в зависимости от ресурсов сервера и количества активных пользователей. После изменения настройки система начнет использовать уже запущенные процессы rphost.exe для новых соединений, что сократит время старта до миллисекунд.
Выясним причину задержки на уровне программного кода. Каждый раз, когда стартует фоновое задание, платформа инициирует новый сеанс. В этот момент в обязательном порядке выполняется обработчик события УстановкаПараметровСеанса, расположенный в Модуле сеанса.
Посмотрим на типичную ошибку: если в этом обработчике прописаны тяжелые запросы к базе данных (например, получение прав доступа, инициализация сложных структур или обращение к внешним веб-сервисам), то время выполнения этого кода напрямую суммируется со временем ожидания запуска задания.
Для оптимизации старта фоновых заданий следует использовать проверку на инициализацию только необходимых параметров. Рассмотрим пример правильного кода в модуле сеанса:
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
// Проверяем, нужно ли устанавливать конкретный параметр
Если ТребуемыеПараметры = Неопределено Тогда
// Код инициализации при первом обращении
Возврат;
КонецЕсли;
// Оптимизация: для фоновых заданий устанавливаем только критичный минимум
Если Найти(СтрокаСоединенияИнформационнойБазы(), "BackgroundJob") > 0 Тогда
// Упрощенная инициализация для фоновых задач
КонецЕсли;
КонецПроцедуры
Проанализируем технологические особенности платформы. Начиная с версии 8.3.16, механизм работы с фоновыми заданиями был значительно переработан. Появилось понятие Пул сеансов. В современных версиях платформа не завершает сеанс фонового задания сразу после его выполнения, а переводит его в «спящее» состояние на короткий период. Если в этот момент поступает команда на выполнение нового задания, оно подхватывает уже существующий инициализированный сеанс.
Если вы используете устаревшую версию платформы (например, 8.3.12, как в рассматриваемом случае), этот механизм работает менее эффективно или отсутствует вовсе. Обновление платформы до актуальных релизов (ветки 8.3.22 и выше) часто само по себе решает проблему долгого старта за счет оптимизации работы с очередью заданий.
Выясним, как инфраструктура сервера влияет на задержки. Одной из скрытых причин долгого отклика при взаимодействии менеджера кластера (rmngr) и рабочих процессов (rphost) является некорректная настройка IPv6 и разрешения имен (DNS).
Когда компоненты кластера обращаются друг к другу по именам серверов, задержка может возникнуть на этапе ожидания ответа от DNS-сервера. Проанализируем следующие действия:
hosts на сервере — пропишите соответствие IP-адреса и имени сервера 1С локально, чтобы исключить внешние запросы.Важно учитывать, что при старте фонового задания в новом рабочем процессе происходит компиляция модулей и загрузка метаданных. В тяжелых конфигурациях, таких как 1С:Бухгалтерия 3.0 или ERP 2.5, этот процесс занимает много времени.
Расширения конфигурации также вносят свой вклад. Даже если функционал расширения не используется в коде фонового задания, платформа обязана проверить применимость расширения к текущему контексту. Если в базе подключено большое количество расширений, это увеличивает объем загружаемых данных в память rphost.exe при его старте.
Рассмотрим проверку: попробуйте временно отключить все расширения и замерить время старта задания. Если задержка существенно уменьшится, следует проанализировать код расширений, особенно в части переопределения методов модуля сеанса или общих модулей с флагом «При сервере».
Разберем еще один неочевидный фактор — получение лицензии. При запуске фонового задания система должна убедиться в наличии свободной лицензии. Если используются многопользовательские программные ключи или поиск ключа идет через HASP License Manager по сети, процесс опроса может занимать несколько секунд, особенно при нестабильном соединении или большой загрузке менеджера лицензий.
Для ускорения процесса рекомендуется:
nnhasp.ini для прямого указания IP-адреса менеджера лицензий, чтобы исключить широковещательные запросы в сети.Подводя итог, можно сказать, что решение проблемы долгого старта фоновых заданий чаще всего кроется в комплексной настройке параметров кластера 1С и оптимизации кода инициализации сеанса. Первоочередным действием всегда должна быть проверка параметра Количество соединений на рабочий процесс, так как именно он в 90% случаев является «бутылочным горлышком» в данной ситуации.