Часто в практике разработчика встречается ситуация: после того как у пользователей (например, бухгалтеров или менеджеров) забирают «Полные права», система начинает работать ощутимо медленнее. Особенно это заметно при открытии форм списков, обновлении данных или проведении документов. В этой статье мы подробно разберем, почему права доступа напрямую влияют на производительность, и как с этим бороться.
Разберем ситуацию, описанную коллегой: при выполнении метода Обновить() для динамического списка наблюдается колоссальная разница в скорости под полными правами и под правами обычного пользователя. Основная причина здесь — механизм RLS (Record Level Security) или ограничение доступа на уровне записей.
Когда у пользователя нет полных прав, платформа 1С перестает доверять его запросам к базе данных «на слово». Для каждой таблицы, к которой обращается запрос (будь то список документов ПриобретениеТоваровИУслуг или связанные регистры), платформа автоматически дописывает дополнительные условия в SQL-запрос. Проанализируем, что происходит внутри системы:
JOIN и условия WHERE, которые проверяют, имеет ли пользователь право видеть конкретную строку (например, по Организации, Складу или Подразделению).Рассмотрим по шагам, как проанализировать, где именно «зависает» система. Для начала воспользуемся встроенным инструментом Замер производительности.
Важно запускать замер именно под тем пользователем, у которого наблюдаются проблемы. Как отметил автор темы, основное время часто уходит на строку Элементы.Список.Обновить(). За этой строкой стоит выполнение тяжелого SQL-запроса с учетом RLS. Чтобы увидеть этот запрос «вживую», нам потребуется настроить Технологический журнал (ТЖ). В файле настроек ТЖ стоит собирать события DBMSSQL (или DBPOSTGRS, в зависимости от СУБД) с фильтром по длительности выполнения запроса.
Проанализируем текст запроса из ТЖ. Вы увидите, что ваш короткий запрос превратился в огромную конструкцию. Если вы обнаружите там многократные соединения с таблицами прав доступа (например, _AccessRights), значит, проблема именно в RLS.
Начиная с версии платформы 8.3.12, компания 1С представила «Производительный режим управления доступом». Разберем, в чем его преимущество. В обычном режиме права вычисляются «на лету» при каждом запросе. В производительном режиме данные об ограничениях кэшируются в специальных вспомогательных таблицах.
Чтобы включить этот режим, выполним следующие действия:
Внимание: После включения этого режима может потребоваться запуск регламентного задания по обновлению данных о правах доступа.
Если замедление происходит при проведении документа, мы можем временно отключить проверку прав для серверных алгоритмов. Рассмотрим пример кода, который позволяет выполнить тяжелую операцию без оглядки на RLS:
УстановитьПривилегированныйРежим(Истина);
// Выполняем действия, требующие высокой скорости и доступа к данным
// Например, проведение документа или расчет итогов
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
УстановитьПривилегированныйРежим(Ложь);
Этот метод эффективно работает в модулях менеджеров или в серверных процедурах общих модулей. Однако помните, что УстановитьПривилегированныйРежим не ускорит динамический список на форме, так как он всегда работает под правами текущего пользователя.
Проанализируем ситуацию, когда в динамическом списке используется произвольный запрос. Как правило, RLS накладывается на каждую таблицу, участвующую в СОЕДИНЕНИИ. Если у вас в запросе 5 таблиц и на каждую действует RLS, производительность упадет в разы.
Попробуем оптимизировать такой запрос:
ПриВыводеСтроки или через функциональные опции).Как упоминалось в обсуждении, часто RLS завязан на параметры сеанса. Выясним причину, если параметры сеанса инициализируются медленно. Если шаблон RLS выглядит как сложный запрос к нескольким справочникам, попробуйте упростить его. Иногда бизнес-логика позволяет ограничить доступ только по одному измерению (например, только по Организации), что значительно ускорит работу SQL-сервера.
Рассмотрим вариант программного управления доступом. Если ваша цель — не защита данных от злоумышленников, а просто удобство интерфейса («чтобы лишнее не мешалось»), можно отказаться от RLS в пользу программных отборов в динамическом списке:
ЭлементОтбора = Список.КомпоновкаДанных.Настройки.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
ЭлементОтбора.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Организация");
ЭлементОтбора.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
ЭлементОтбора.Использование = Истина;
ЭлементОтбора.ПравоеЗначение = ТекущаяОрганизацияПользователя;
Такой отбор работает значительно быстрее, чем RLS, так как не перестраивает структуру самого SQL-запроса на уровне ядра платформы.
Мы выяснили, что права доступа — это не только вопрос безопасности, но и вопрос производительности. Если после отключения полных прав система начала «тормозить», первым делом нужно анализировать шаблоны RLS и индексы в базе данных. Переход на производительный режим управления доступом и грамотное использование привилегированного режима в большинстве случаев решают проблему медленной работы документов и списков.