При использовании технологии расширений в среде 1С:Предприятие 8.3 программисты часто сталкиваются с неожиданным поведением системы: время запуска сеанса увеличивается в разы. Ситуация, когда конфигурация без расширения загружается за 30 секунд, а с ним — за 6 минут, является критической и требует детального разбора. В этой статье мы проанализируем технические причины такого замедления, рассмотрим влияние структуры метаданных на скорость инициализации и определим шаги по оптимизации системы.
Прежде всего, проанализируем, что происходит «под капотом» платформы в момент запуска. Когда пользователь открывает информационную базу, платформа не просто загружает основную конфигурацию. Она выполняет динамическую сборку всей прикладного решения в оперативной памяти. Этот процесс включает в себя:
&Вместо, &Перед или &После.Важно понимать, что в ранних версиях платформы (до 8.3.14) этот процесс не был достаточно оптимизирован. Каждый заимствованный объект увеличивает время «сборки» не линейно, а по сложной зависимости, особенно если объекты связаны между собой.
Одной из главных причин замедления, описанной в ситуации, является массовое заимствование объектов исключительно для управления правами доступа. Рассмотрим, почему это критично. Когда вы добавляете в расширение 30 ролей и подтягиваете в него десятки документов и справочников для ограничения доступа, платформа вынуждена для каждого сеанса строить огромную матрицу прав.
Проблема ролей в расширении: В момент загрузки система должна вычислить итоговое право на каждый объект, суммируя права из основной конфигурации и всех расширений. Если в расширении заимствовано много объектов «без реквизитов», только ради галочек в ролях, платформа все равно тратит время на инициализацию структуры этих объектов в контексте расширения. Чем больше пар «Объект — Роль», тем дольше длится фаза проверки полномочий при старте.
Версия платформы 8.3.11, упомянутая в проблеме, относится к периоду активного становления технологии расширений. В то время механизмы кэширования скомпилированных расширений на сервере были реализованы не в полной мере. Рассмотрим основные технические нюансы того времени:
Чтобы уменьшить время загрузки с 6 минут до приемлемых значений, проанализируем следующие шаги:
Это самый эффективный метод. Начиная с версий 8.3.12 и 8.3.14, разработчики 1С провели колоссальную работу по оптимизации расширений. В версиях 8.3.18+ загрузка расширений происходит значительно быстрее за счет разделения потоков инициализации. Если ваша конфигурация позволяет, рекомендуем перейти на актуальный релиз ветки 8.3.22 или выше.
Проанализируем состав вашего расширения. Часто программисты заимствуют объекты «целиком» или «на всякий случай». Это ошибка. Выясним, как оптимизировать состав расширения:
Если расширение используется преимущественно для разграничения прав, рассмотрим альтернативные варианты. Вместо создания десятков ролей в расширении, можно попробовать использовать программное ограничение доступа на уровне кода в расширяемых модулях менеджеров или через механизмы БСП (Библиотеки стандартных подсистем), если версия конфигурации это позволяет.
Иногда аномально долгая загрузка вызвана некорректным состоянием кэша метаданных. Попробуем выполнить следующие действия:
snccntx в каталоге сеансовых данных сервера.%AppData%\1C\1Cv8 и %LocalAppData%\1C\1Cv8).Посмотрим на пример того, как НЕ стоит делать, и как сделать правильно. Допустим, нам нужно изменить процедуру проведения документа РеализацияТоваровУслуг и добавить на него права для новой роли.
Неправильно: Заимствовать документ со всеми формами, реквизитами и макетами, а также все связанные с ним регистры накопления.
Правильно: Заимствовать только сам объект «Документ» (без реквизитов), заимствовать только нужную процедуру модуля объекта и создать роль, в которую добавить только необходимые права. Проанализируем программный код в расширении:
&Вместо("ОбработкаПроведения")
Процедура Расш1_ОбработкаПроведения(Отказ, РежимПроведения)
// Выполняем стандартную логику
ПродолжитьВызов(Отказ, РежимПроведения);
// Добавляем свою логику
Если Не Отказ Тогда
// Наш код
КонецЕсли;
КонецПроцедуры
Использование метода ПродолжитьВызов позволяет платформе более эффективно строить дерево вызовов, чем полная замена кода, что также косвенно влияет на стабильность работы системы под нагрузкой.
Если ваша база работает в режиме совместимости (например, с версией 8.3.10), то даже установка новой платформы 8.3.20 не даст полного эффекта для расширений. Платформа будет использовать старые алгоритмы обработки метаданных для обеспечения идентичности поведения. Если есть возможность, попробуйте постепенно повышать режим совместимости конфигурации, предварительно протестировав стабильность работы всех функций.
Подведем итоги. Шестиминутная загрузка — это следствие «тяжелого» расширения на старой платформе, работающей в режиме совместимости с обычными формами. Для решения проблемы мы рекомендуем:
Следуя этим рекомендациям, мы сможем добиться возвращения скорости загрузки к нормальным показателям (30–60 секунд), обеспечив при этом необходимый функционал расширения.