Внедрение и сопровождение крупных корпоративных систем на базе 1С:ERP Управление предприятием часто ставит перед архитекторами и разработчиками сложный выбор: вносить изменения напрямую в основную конфигурацию или использовать механизм расширений. Бытует мнение, что расширения — это «абсолютное зло», которое неизбежно приводит к критическому замедлению работы системы, особенно при увеличении объемов данных и количества активных пользователей.
В рамках этой статьи мы подробно разберем, действительно ли перенос программного кода и метаданных в расширение снижает производительность. Мы проанализируем официальную статистику вендора, заглянем «под капот» СУБД, изучим механизм работы таблиц расширений, рассмотрим эволюцию платформы 1С:Предприятие 8.3 и выработаем практические рекомендации по оптимизации высоконагруженных систем.
---
При обсуждении производительности расширений часто всплывают пугающие цифры: +26% к времени выполнения операций и +39% к загрузке процессора (CPU). Проанализируем, откуда взялись эти показатели и что они означают на практике.
Эта статистика реальна. Фирма «1С» официально опубликовала результаты синтетических нагрузочных тестов на портале ИТС. Однако, чтобы правильно интерпретировать эти данные, необходимо детально изучить условия, при которых проводился эксперимент:
&Вместо, &Перед или &После) и передать управление соответствующему обработчику.---
Существует распространенное заблуждение, что при добавлении реквизитов в существующие объекты через расширение база данных начинает «плодить» копии таблиц, которые постоянно взаимодействуют друг с другом через тяжелые соединения (JOIN), тем самым перегружая СУБД. Выясним, как этот процесс устроен на самом деле.
Рассмотрим два сценария модификации данных в расширении:
Сценарий 1: Создание новых объектов метаданных.
Если мы создаем в расширении собственный справочник или документ, платформа генерирует в СУБД обычную новую физическую таблицу. В этом случае работа с объектом ничем не отличается от работы с объектами основной конфигурации. Накладных расходов на производительность здесь нет.
Сценарий 2: Добавление реквизита в существующий (заимствованный) объект.
Если мы заимствуем из основной конфигурации справочник (например, Справочник.Номенклатура, физическая таблица которого в СУБД называется _Reference75) и добавляем в него новый реквизит в расширении, платформа действует следующим образом:
_X (например, _Reference75X1)._Reference75 больше не используется системой для оперативной работы. Все запросы платформы (чтение, запись, выборки) перенаправляются исключительно на новую расширенную таблицу _Reference75X1.Таким образом, никакого «общения» или постоянного связывания двух таблиц в процессе работы пользователей не происходит. СУБД выполняет запросы к одной физической таблице.
Однако у этого механизма есть очевидные минусы:
---
Разберем, как перенос программного кода в расширение влияет на оперативную память и скорость работы сервера приложений 1С.
Компиляция модулей в платформе «1С:Предприятие» происходит по требованию (on-demand). Когда пользователь открывает форму или запускает обработку, сервер компилирует соответствующий модуль в байт-код и кэширует его. Если код перенесен в расширение, платформа тратит дополнительное время на компиляцию аналогичного модуля расширения и связывание его с основным модулем.
Посмотрим на пример вызова перехваченного метода. Допустим, у нас есть процедура в основной конфигурации:
Процедура РассчитатьСкидку(ДокументОбъект)
// Основной алгоритм расчета
КонецПроцедуры
Мы решили кастомизировать этот расчет и перенесли логику в расширение с использованием аннотации &Вместо:
&Вместо("РассчитатьСкидку")
Процедура Расш1_РассчитатьСкидку(ДокументОбъект)
// Вызов оригинального метода, если это необходимо
ПродолжитьВызов(ДокументОбъект);
// Наша кастомная логика
ПровестиДополнительныйРасчет(ДокументОбъект);
КонецПроцедуры
При вызове метода РассчитатьСкидку платформа совершает дополнительный шаг в цепочке вызовов (перенаправление в расширение). Если эта процедура вызывается интерактивно при нажатии кнопки пользователем — разница во времени составит микросекунды, которые человеческий глаз заметить не способен. Но если данный метод вызывается внутри цикла обработки сотен тысяч строк при проведении документов, накладные расходы на диспетчеризацию вызовов начнут накапливаться, снижая общую пропускную способность системы.
---
Многие разработчики отказывались от расширений из-за жестких ограничений платформы прошлых лет. Проанализируем, как фирма «1С» развивала этот механизм в последних релизах:
Ранее в расширениях нельзя было создавать собственные подписки на события заимствованных объектов, что заставляло разработчиков писать громоздкий код в модулях объектов или перехватывать события форм. Решение: Начиная с версии платформы 8.3.17, разработчики могут как заимствовать существующие подписки, так и создавать собственные полноценные подписки на события непосредственно внутри расширения.
Отсутствие возможности создавать предопределенные элементы в расширениях сильно усложняло логику завязки кода на конкретные элементы справочников. Решение: В версии 8.3.20 появилась поддержка создания предопределенных элементов для собственных справочников расширения, а начиная с версии 8.3.21, платформа позволяет добавлять предопределенные элементы даже в заимствованные объекты основной конфигурации.
В старых релизах (до 8.3.20) существовала критическая проблема: если реквизит основной конфигурации имел тип ЛюбаяСсылка, а в расширении создавался новый справочник, то при попытке записать ссылку на этот справочник в данный реквизит значение сбрасывалось в Неопределено. Решение: Начиная с версии 8.3.20, типы данных формируются платформой динамически на лету, что полностью решило проблемы совместимости с Библиотекой стандартных подсистем (БСП).
---
Для того чтобы расширение в высоконагруженной системе ERP работало стабильно, необходимо обратить внимание на несколько ключевых настроек платформы и СУБД.
А. Флаг «Использовать основные роли для всех пользователей»
При создании нового расширения этот флаг по умолчанию включен. Если оставить его активным, платформа при каждом обращении любого пользователя к любому объекту будет динамически вычислять и накладывать роли расширения. На базах с сотнями и тысячами активных пользователей это приводит к колоссальной нагрузке на процессор сервера приложений и СУБД.
Рекомендация: Всегда отключайте этот флаг, если ваше расширение не содержит ролей, которые действительно должны применяться ко всем без исключения пользователям базы данных.
Б. Влияние безопасного режима
Если для расширения установлен параметр Безопасный режим = Истина, платформа накладывает жесткие ограничения на выполнение серверного кода и обращение к внешним ресурсам. Попытки обойти эти ограничения или частые проверки прав в безопасном режиме могут замедлить работу интерфейса.
Рекомендация: Для доверенных расширений в корпоративных системах (особенно ERP) безопасный режим и защиту от опасных действий рекомендуется отключать, предварительно выполнив аудит кода.
В. Тонкая настройка SQL Server
Поскольку расширения активно работают с временными таблицами и реструктуризацией данных, СУБД должна быть настроена оптимально. Проверим базовые настройки MS SQL Server для работы с высоконагруженной базой 1С:
---
Подведем итог. Расширения конфигурации в 1С — это современный, мощный и безопасный инструмент кастомизации систем, который при правильном подходе не вызывает деградации производительности.
Чтобы ваша ERP-система работала быстро, соблюдайте следующие правила архитектуры:
Номенклатура, Партнеры, ЗаказКлиента). Помните о создании таблиц с суффиксом _X и накладных расходах на реструктуризацию. Если реквизитов много, рассмотрите возможность использования механизма дополнительных реквизитов и сведений или создания отдельных связанных регистров сведений.