Многие технические специалисты, работающие с тяжелыми конфигурациями на базе 1С:Предприятие 8.3, такими как «Комплексная автоматизация 2.4», ERP 2 или «Управление торговлей 11», замечают странную особенность. Отчеты и формы, которые «летают» под пользователем с полными правами, начинают работать на 30–50% медленнее, как только ими начинает пользоваться обычный сотрудник с ограниченным профилем. Даже если RLS (ограничение доступа на уровне записей) официально отключен в настройках, разница в производительности остается ощутимой.
В этой статье мы подробно разберем, почему так происходит, заглянем «под капот» платформы и выясним, какие механизмы замедляют работу обычных пользователей.
Рассмотрим ситуацию с точки зрения ядра платформы 1С. Роль Полные права не является просто «набором всех галочек» в метаданных. Для движка платформы это особый флаг. Когда запрос к базе данных выполняет пользователь с административными правами, система полностью отключает механизмы проверки прав доступа на этапе формирования SQL-запроса. Программа «доверяет» такому пользователю априори.
Для любого другого профиля, даже если вы выдали ему абсолютно все права, но не назначили роль Полные права, платформа обязана запустить алгоритм проверки. Каждый раз перед отправкой запроса в СУБД сервер приложений 1С анализирует: имеет ли пользователь право на эту таблицу, на эти поля, есть ли ограничения RLS. Этот процесс создает накладные расходы на процессорное время сервера приложений, которые отсутствуют у администратора.
Проанализируем работу механизма «Универсального RLS», который активно используется в современных конфигурациях. В настройках системы часто встречается константа ОграничиватьДоступНаУровнеЗаписейУниверсально. Многие полагают, что ее выключение или упрощение должно уровнять скорость работы пользователей, но это не совсем так.
При включенном универсальном механизме платформа переводит проверку прав в режим работы через специальные регистры, такие как КлючиДоступаКОбъектам. Даже если для конкретного отчета ограничений нет, платформа все равно модифицирует исходный запрос. Выясним причину: система пытается выполнить LEFT JOIN основной таблицы запроса с таблицей ключей доступа. Оптимизатор SQL-запросов не всегда может эффективно отсечь эти «пустые» или всегда истинные соединения. В результате план запроса усложняется, что и приводит к деградации производительности.
Пример упрощенного условия, которое платформа может добавить в WHERE для обычного пользователя, даже если доступ разрешен:
ГДЕ (ИСТИНА) И (ИСТИНА) И (Склад В (ВЫБРАТЬ Ключ ИЗ РегистрСведений.КлючиДоступа))
Администратор же выполнит чистый запрос без этих дополнительных проверок.
Посмотрим на профили пользователей в КА 2.4. Типовой профиль часто состоит из 50–100 различных ролей. Каждая роль в системе — это отдельный объект метаданных со своими правилами. Когда платформа формирует SQL-запрос, она обязана проанализировать ограничения для каждой роли, входящей в профиль пользователя.
Если у пользователя 50 ролей, и в каждой из них прописан шаблон RLS (даже самый простой), парсеру запросов 1С нужно обработать и объединить метаданные всех этих ролей. В итоге генерируются громоздкие конструкции в секции WHERE с множеством условий OR. Существует известный технический факт: один пользователь с одной ролью работает быстрее, чем пользователь с 50 ролями, которые в сумме дают те же самые права. Это связано с колоссальными затратами на парсинг запроса на сервере 1С.
Разберем, почему тормозит не только сам расчет отчета, но и открытие его формы. Для обычного пользователя 1С при отрисовке интерфейса выполняет проверку прав на каждый элемент:
В сложных формах КА 2.4 могут быть сотни реквизитов. Для администратора эти проверки игнорируются, а для обычного пользователя система совершает сотни микро-запросов к кэшу прав. Это создает ощущение «вязкости» интерфейса.
Большинство сложных отчетов (например, по себестоимости или валовой прибыли) строятся на базе временных таблиц. Проанализируем ситуацию: если код отчета написан без явного использования привилегированного режима, то при заполнении каждой временной таблицы платформа выполняет проверку прав.
Если вы хотите ускорить выполнение отчета для пользователя, можно использовать метод УстановитьПривилегированныйРежим(Истина) в программном коде формирования отчета. Рассмотрим пример:
Процедура ПриКомпоновкеРезультата(РезультатОформления, ДанныеРасшифровки, СтандартнаяОбработка)
УстановитьПривилегированныйРежим(Истина);
// Здесь происходит формирование тяжелого запроса
// Теперь платформа не будет проверять права на каждую таблицу
КонецПроцедуры
Это позволяет сократить время выполнения запроса до уровня администратора, так как платформа перестанет накладывать условия RLS внутри этого блока кода.
Выясним еще одну причину, связанную с SQL-сервером. SQL-сервер кэширует планы запросов, ориентируясь на их текст. Текст запроса от администратора и текст запроса от пользователя с RLS — это два разных текста. Из-за добавления неявных условий проверки прав планы запросов для обычных пользователей могут быть менее оптимальными. Статистика SQL-сервера может «сбиваться» на сложных соединениях с таблицами прав, выбирая неэффективные индексы.
Замедление на 30–50% под ограниченными правами в системах уровня ERP считается «штатным», хотя и неприятным поведением. Чтобы минимизировать этот эффект, рекомендуется:
RLS (регистры ключей доступа).Таким образом, основная причина медленной работы кроется не в самом факте ограничения данных, а в огромной избыточности ролевой модели и затратах платформы на динамическую проверку прав, которые «Полные права» просто обходят стороной.