Почему долго обновляется конфигурация базы данных при изменении кода в расширении на платформе 8.3.27?

← На главную

Переход на новые версии платформы 1С:Предприятие часто приносит не только новые возможности, но и неожиданные изменения в привычных рабочих процессах. Одной из таких проблем в ветке 8.3.27 стало существенное замедление процесса обновления конфигурации базы данных (БД) при работе с расширениями. Даже минимальное изменение программного кода в модуле расширения может приводить к ожиданию длительностью в минуту и более, что значительно снижает темп разработки.

В этой статье мы подробно разберем, почему так происходит, какие внутренние механизмы платформы задействованы в этом процессе и как можно ускорить обновление конфигурации в условиях современной разработки на базе 1С:Зарплата и Управление Персоналом и других тяжелых решений.

Причины замедления: механизмы валидации и изменения в 8.3.27

Проанализируем ситуацию: начиная с версии 8.3.27, разработчики 1С значительно усилили контроль целостности данных при применении расширений. Рассмотрим основные факторы, влияющие на скорость:

Глубокая проверка связей метаданных. Если в вашем расширении содержатся собственные объекты (справочники, документы) или, что еще важнее, добавлены новые реквизиты в типовые объекты основной конфигурации, платформа запускает полный цикл верификации. Даже если вы изменили всего одну строку в программном коде, система обязана убедиться, что структура таблиц БД в расширении соответствует логике основной конфигурации.
Реструктуризация «на лету». Добавление собственных реквизитов в расширение переводит процесс обновления из категории «простое обновление модулей» в категорию «реструктуризация базы данных». В 8.3.27 механизмы сопоставления имен (mapping) стали работать медленнее из-за дополнительных проверок безопасности.
Особенности кэширования. На новой платформе замечено агрессивное перестроение индексов временных таблиц расширений. Это вызывает повышенную нагрузку на дисковую подсистему в момент нажатия кнопки «Обновить конфигурацию ИБ».

Решение 1: Обновление платформы до стабильных билдов

Как показывает практика и опыт участников профессиональных сообществ, первые релизы ветки 8.3.27 (например, 8.3.27.2130) содержали неоптимальные алгоритмы работы с системными таблицами при наличии в расширениях собственных регистров или документов. Выясним, как исправить ситуацию самым простым способом.

Протестируем поведение системы на более свежих сборках. В релизе 8.3.27.2214 и выше были применены первые патчи, оптимизирующие запросы к метаданным расширений. Пользователи отмечают, что время обновления сокращается примерно на 20–30% по сравнению с первыми выпусками ветки. Поэтому первым шагом при возникновении подобных задержек должна быть проверка наличия более актуального исправительного релиза платформы.

Решение 2: Разделение расширений на «тяжелые» и «легкие»

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

Рассмотрим стратегию разделения:

Создадим «Расширение_Данные». В него мы вынесем все новые справочники, документы и дополнительные реквизиты. Это расширение будет обновляться редко — только при изменении структуры данных.
Создадим «Расширение_Логика». В нем мы оставим только программный код, формы и переопределяемые модули. В этом расширении не должно быть собственных объектов, создающих таблицы в БД.

При таком подходе изменение кода в «легком» расширении будет происходить практически мгновенно, так как платформе не потребуется инициировать процессы проверки целостности таблиц БД.

Влияние режима совместимости и конфигурации ЗУП

Проанализируем ситуацию со стороны прикладного решения. Конфигурация Зарплата и Управление Персоналом (ЗУП) является одной из самых сложных с точки зрения метаданных. В ней используется огромное количество функциональных опций и подписок на события. Платформа 8.3.27 при обновлении любого расширения пытается актуализировать связи с этими опциями.

Если ваша основная конфигурация находится в высоком режиме совместимости (например, 8.3.24), то механизмы расширений работают по новым алгоритмам безопасности. Посмотрим на типичный сценарий: вы заимствуете форму документа и добавляете в нее обработчик события. Платформа в версии 8.3.27 проверит не только ваш код, но и все заимствованные элементы формы на предмет их соответствия текущей структуре основной конфигурации, что на тяжелых формах ЗУП занимает значительное время.

Технические нюансы работы с расширениями в коде

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


// Получим список всех установленных расширений конфигурации
МассивРасширений = РасширенияКонфигурации.Получить();

Для Каждого ТекущееРасширение Из МассивРасширений Цикл
    // Проверим, активно ли расширение и нет ли ошибок применения
    Если ТекущееРасширение.Активно Тогда
        Сообщить("Расширение: " + ТекущееРасширение.Имя + " применено успешно.");
    Иначе
        Сообщить("Внимание! Расширение: " + ТекущееРасширение.Имя + " не активно.");
    КонецЕсли;
КонецЦикла;

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