От экспертов «1С-Рарус»: Производительность нового RLS в 1С БСП 3. Переходить или нет?

Производительность механизма ограничения прав на уровне записи в «1С» (RLS)

Одним из известных источников проблем производительности в «1С» является механизм RLS (Record Level Security). Связано это, как мы увидим ниже, с построением неоптимального плана запроса. Часто на больших проектах, проектные команды доходили вплоть до отказа от использования этого механизма и разрабатывали на уровне прикладного кода свои механизмы.

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

Декларируется значительное ускорение при переключении на данный режим, в отдельных случаях до 100 раз.

В рамках данной статьи проведен тщательный сравнительный анализ нового подхода и основные нюансы по переходу на него.

Архитектурный обзор

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

Принципиальным моментом для нас является то, что сами тексты шаблонов значительно отличаются в новом и старом подходе. В новом они ультракомпактны. За выбор между новым и старым RLS отвечает константа «ОграничениеДоступаНаУровне
ЗаписейУниверсально»:

Далее платформенными механизмами для пользователей с ограниченными правами применяются шаблоны ограничений, что добавляет к запросам на чтение / добавление / изменение записей на уровне СУБД текст запроса на проверку видов доступа, настроенных при помощи стандартного механизма настройки видов доступа, например, как показано на скриншоте ниже.

В старом RLS участвуют шаблоны «ПоЗначениям», «ПоЗначениямРасширенный», «ПоЗначениямИНаборам
Расширенный», «ПоНаборамЗначений». Они имеют большое количество параметров, где мы в простейшем случае указываем имя объекта и право, которое мы ограничиваем, а дальше попарно перечисляем вид доступа, который ограничиваем и имя реквизита объекта, по которому производится фильтрация:

В самом шаблоне для каждой пары параметров «вид доступа — имя реквизита» добавляется текст проверки ограничения, при этом используются регистры сведений:

• ТаблицыГруппДоступа,
• ЗначенияГруппДоступа.

Недостаток такого подхода заключается в масштабируемости, чем больше видов доступа настраиваем для объекта, тем больше финальный текст запроса в СУБД и количество левых соединение в нем:

Это может привести к неправильному использованию индексов и выбору неоптимального плана запроса на больших данных, о чем будет рассказано позже.

В новом же RLS используются шаблоны доступа «ДляОбъекта» и «ДляРегистра». В перечисленных шаблонах используются уже другие сущности для проверки прав доступа.

Регистр сведений для хранения настроек:

• ПараметрыОграниченияДоступа.

Регистры сведений для проверки ограничений:

• КлючиДоступаКОбъектам,
• КлючиДоступаПользователей.

Справочники ключей:

• КлючиДоступа,
• НаборыГруппДоступа.

Отличительной особенностью нового механизма является то, что он позволяет не усложнять проверку прав доступа дополнительными соединениями с основным запросом при увеличении количества видов доступа, настраиваемых для объекта. Текст запроса проверки прав доступа будет фиксированным, различаются только параметры:

Достигается это за счет устройства регистров сведений для проверки ограничений «КлючиДоступаКОбъектам» и «КлючиДоступаПользователей».

Регистры имеют следующую структуру:

Здесь объект — это ссылка на конкретный объект в информационной базе (например, «Приходная накладная 0001 от 01.08.2020»), а ключ доступа пользователей — это специальный справочник, представляющий из себя составной ключ, содержащий определенную комбинацию значений видов доступа:

Стоит обратить внимание на реквизиты Значение 1, Значение 2 и т. д. В них будет содержаться комбинация конкретных значений видов доступа. Например, для видов доступа Организация, Структурная единица это могут быть «Ресторан», «Кухня-цех» или «Кафе Аленка», «Кухня-склад» и т. д.

Регистр ключей доступа к объектам, а также сами ключи доступа обновляются регламентно, а для быстрого поиска ключа в информационной базе предусмотрен реквизит «Хеш». Он вычисляется по специальной хеш функции и позволяет быстро понять, существует ли уже в системе ключ с такой комбинацией значений или нет.

Регистр ключей доступа пользователей в измерении «Пользователь» содержит справочник ключей пользователей, к которым применяется ограничение, а также справочник ключей доступа к объектам.

Таким образом при проверке ограничений доступа вне зависимости от количества настроенных для конкретного проверяемого объекта видов доступа запрос всегда будет дополняться одним соединением с регистром «Ключи доступа к объектам» по проверяемому объекту и с регистром «Ключи доступа пользователей» по текущему пользователю:

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

Переход со старого на новый и обратно

Если вы используете старый механизм RLS (или не используете ограничение на уровне записей вовсе) и хотите перейти на новый, то можно это сделать, выполнив несложную последовательность действий:

• Убедиться, что ваша конфигурация разработана на версии БСП 3.0.1 и выше. Если это не так, то необходимо будет выполнить соответствующее обновление.
• Для работы с новым механизмом RLS необходимо включить константы «Ограничивать доступ на уровне записей» и «Ограничивать доступ на уровне записей Производительный». Не во всех типовых решениях вторая константа вынесена в интерфейс, поэтому проще всего это сделать через меню «Все функции»:

  

• Далее, если в конфигурации есть доработки по ролям, то нам необходимо в эти роли прописать шаблоны ограничений «ДляОбъекта» и «ДляРегистра». Сделать это можно несколькими способами:
  • Если ролей немного, то копируем шаблоны из какой-либо типовой роли вручную.
  • Если же ролей большое количество, то можно воспользоваться обработкой «ПроверкаВнедренияБСП», которая входит в дополнительные файлы поставки БСП.
  • Третий вариант — самостоятельно написать обработку, которая выгрузит конфигурацию в файлы и допишет новые шаблоны в доработанные роли.
• В общем модуле «УправлениеДоступом
  Переопределяемый» в процедуру «ПриЗаполненииСписковС
  ОграничениемДоступа» дописать объекты, которые будут использовать новый механизм проверки ограничений на уровне записей:

  

• В модуле менеджера каждого из объектов, который был описан в предыдущем шаге, добавить функцию «ПриЗаполненииОграничений
  Доступа», в которой на специальном языке описания ограничений указать какие виды доступа необходимо проверить:

  

Подробное описание языка ограничений есть на ИТС, а также синтаксис языка ограничений находится в модуле «УправлениеДоступомСлужебный» в функции «СинтаксисЯзыка».

• В форме элемента объекта в функции «ПриЧтенииНаСервере» дописать следующий вызов общего модуля подсистемы «Управление доступом»:

  

• В определяемых типах «ВладелецЗначенийКлючей
  ДоступаДокумент», «ВладелецЗначенийКлючей
  ДоступаНаборЗаписей», «ВладелецЗначенийКлючей
  ДоступаОбъект» добавить вышеописанные объекты / наборы записей регистров.
• Также для регистров сведений или накопления необходимо в справочнике «Идентификаторы объектов метаданных» добавить предопределенные элементы в соответствии с уже существующими:

  

• Далее необходимо запустить «1С» в режиме «Предприятие» с ключом обновления информационной базы, чтобы система выполнила процедуры, связанные с переходом на новый механизм ограничения доступа на уровне записей:

  

• Последним пунктом будет убедиться в том, что регламентное задание по обновлению ключей доступа к данным выполнено и справочник ключей доступа заполнился. Для этого в БСП есть специальная форма «Обновление доступа на уровне записей», которая обычно открывается из настроек программы. Справочник «Ключи доступа» можно открыть через «Все функции» и убедиться, что он не пустой.

  

Таким образом осуществлен переход на использование нового механизма ограничений на уровне записей на базе конфигурации, разработанной на БСП 3.0.1 и выше.

Стоит отметить, что после выполненных действий не составит труда вернуться на старый механизм RLS и обратно, если это требуется.

Для этого необходимо изменить константу «Ограничивать доступ на уровне записей универсально». Это достигается благодаря тому, что старый и новый механизм ограничения доступа на уровне записей используют разные объекты метаданных.

При переключении константы система просто станет использовать другие регистры для проверки ограничений. Дополнительно при переключении на новый механизм RLS будет произведено обновление ключей доступа к объектам и ключей доступа пользователей.

Сравнительное тестирование

Итак, приступим непосредственно к проведению сравнительного тестирования двух систем RLS.

Параметры стенда:

• Две базы с одинаковой конфигурацией «1С:УНФ 8. Управление предприятием общепита» ред. 1.6.21.103 с БСП ред. 3.1.3.179.
• Платформа 1С: 8.3.16.1296.
• Операционная система: Windows Server 2012 R2.
• База данных: Microsoft SQL Server 2017 64х.
• Конфигурация сервера:
  • Процессор: Intel Xeon X5680 12M Cache 3.33, 6 ядер, 2 шт.
  • Оперативная память: 192 ГБ DDR3.
  • Дисковые накопители: HGST HUH 721212ALE604 (файлы баз данных), Intel SSDSC2BA800G4 (системный диск, tempdb).
• СУБД и кластер «1С» на одном сервере.

Параметры операций для тестирования

В качестве основных объектов наблюдения были выбраны:

• Документ «Приходная накладная».
• Регистр накопления «Запасы». Собственно, этот регистр двигается при проведении исследуемого документа.

Операции:

• Запись и проведение документов «Приходная накладная».
• Выполнение запросов:
  1. Выборка документов «Приходная накладная» со всеми реквизитами без табличной части, за выбранный период пользователю доступно 22–25 тыс. документов.
  2. Аналогичная выборка из п. 1, но ограниченная первыми 45 элементами. Число 45 выбрано не случайно, такое количество строк платформа обычно выбирает при запросах в динамических списках.
  3. Выборка из виртуальной таблицы «обороты» регистра накопления «Запасы», за выбранный период пользователю доступно ~ 22-25 тыс. записей.
  4. Аналогичная выборка из п. 3, но ограниченная первыми 45 элементами.

 Документ «Приходная накладная»

Для документа настроены ограничения доступа по полям «Организация», «Контрагент», «Структурная единица».

Регистр накопления «Запасы»

Для регистра настроены ограничения доступа по измерениям «Организация» и «Структурная единица».

Настройка доступа и подготовка баз

Для тестового пользователя были настроены ограничения по видам доступа:

• «Организации» — доступно 1 значение, остальные запрещены.
• «Структурные единицы» — доступно 1 значение, остальные запрещены.

За основу взята демо-база, в которой были массово созданы документы типа «Приходная накладная» по организации доступной пользователю и по трем складам, доступен из которых только один. К началу эксперимента в обеих базах было порядка 100 тыс. документов, из которых пользователю с ограниченными правами доступно 35–37 тыс.

Настройки

Замеры будем производить несколькими путями:

• замер времени выполнения кода, с помощью функции ТекущаяУниверсальная
  ДатаВМиллисекундах();
• замер производительности «1С»;
• технологический журнал «1С»;
• системный монитор производительности;
• расширенные события MS SQL — для получения планов запросов.

Настройка системного монитора производительности (performance monitor)

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

• Processor\% Processor Time,
• Memory\ Available Mbytes,
• Memory\Pages/sec,
• Physical Disk\ Avg. Disk Queue Length,
• Physical Disk\ Avg. Disk sec transfer.

Дополнительно включим счетчики MS SQL Server для отслеживания работы с буферным кэшем:

• Buffer manager\Page life expectancy,
• Buffer manager\Buffer cache hit ratio,
• Plan Cache\Plan cache hit ratio,
• Buffer Manager\Page reads/sec,
• Buffer Manager\Page writes/sec,
• Buffer Manager\Lazy writes/sec.

Настройка технологического журнала

Используем следующий файл настройки ТЖ — включен мониторинг событий CALL, SCALL, SDBL и DBMSSQL, с отбором по выбранной базе.

Настройка механизма расширенных событий MSSQL

Для получения планов запросов выбираем следующее событие:

• query_post_compilation_showplan

  На закладке «Filter» устанавливаем фильтр по имени базы:

• database_id = <ИмяБазы>

  Внешний вид настройки лога расширенных событий:

Результаты тестирования старого и нового механизмов RLS

Для простоты обозначим далее:

• RLSOld — база со старой RLS.
• RLSNew — база с новой RLS.

Замеры времени

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

Запись

Чтение

По таблице видно, что RLSNew несколько проигрывает в записи, но существенно выигрывает при чтении данных. 

Далее мы проанализируем планы запросов, участвующих в тестировании чтения и проведем комплексный тест проведения 100 документов, чтобы выяснить в чем кроется разница.

Тест чтения — Планы запросов и системный монитор

С помощью extended events и perfmon попробуем проанализировать планы запросов и нагрузку на оборудование.

Выборка документов «Приходная накладная»

Первый тест — запрос по всем реквизитам документа «Приходная накладная»

RLSOld — длительность 6487374 мкс ~ 6,5 сек.

RLSNew — длительность 569894 мкс ~ 0,5 сек.

Как можно заметить — план запросов для RLSNew гораздо компактнее, чем RLSOld. Подробно разбирать все операторы не будем, по оценке планировщика в целом видно, что врезка RLS в прежней системе требует в несколько раз больше ресурсов чем в новой.

Обратим внимание на пару моментов, которые указывают на то, что план запроса в RLSOld не оптимален:

1. Наличие операторов Index Spool и Row Count Spool

Операторы вида Spool означают перенос части данных в tempdb на жесткий диск. Как правило это связано:

• Либо с недостатком оперативной памяти. Это не наш случай, для SQL сервера выделено 50ГБ.
• Либо, если планировщик «не уверен» в запросе и не смог просчитать план достаточно точно. Вероятнее всего так и есть.
  

2. Наличие «толстых» строк на входе у операторов Nested Loops

Как правило, планировщик запросов выбирает оператор соединения Nested Loops в ситуации, когда в обеих или одной из таблиц строк мало.

По плану видно, что планировщик ошибся в оценке. Это также указывает на то, что запрос сложен для оценки.

Очевидно эти факты есть подтверждение того, что прежняя система RLS создает запросы, которые могут вызывать проблемы для планировщика, о чем было написано ранее в блоке архитектуры.

Монитор производительности

Ниже приведен лог, записанный при выполнении 50 запросов в цикле.

Cache hit ratio — показывает процент планов запроса, которые получены из кэша, чем он меньше, тем больше планов SQL Server рассчитывает заново.

Выборка документов «Приходная накладная» (первые 45 строк)

RLSOld — длительность 8705 мкс ~ 0,009 с.

RLSNew — длительность 3136 мкс ~ 0,003 с.

При ограниченном количестве строк в плане RLSNew процент времени выборки из таблицы по отношению к добавке RLS уменьшился. В плане RLSOld исчез оператор Index Spool, но Row Count Spool остался.

По счетчикам системного монитора ничего примечательного не обнаружено, за исключением времени выполнения (запрос выполнялся 5000 раз).

Выборка из регистра накопления «Запасы»

Следующий тест — запрос по всем полям виртуальной таблицы «обороты» регистра накопления «Запасы».

RLSOld — длительность 591352 мкс ~ 0,59 сек.

RLSNew — длительность 289880 мкс ~ 0,29 сек.

Обратим внимание на следующие моменты, влияющие на производительность:

• В RLSOld присутствуют операторы Index Spool и Row Count Spool.
• В обоих планах есть оператор Sort, однако планы построены таким образом, что в RLSOld этот оператор находится до соединения с добавкой RLS и получает на вход ~ 73 тыс. строк, в то время как в RLSNew оператор Sort расположен после соединения и получает на вход только ~ 23 тыс. строк.

Соединение и Sort в RLSOld:

Соединение и Sort в RLSNew:

Для записи мониторинга производительности запрос выполнялся 300 раз. По логу видно, что оба запроса активно используют диск C (на котором расположена база tempdb), при этом очередь к диску (зеленая линия) во время запроса в RLSNew значительно ниже — максимум ~ 0,5, против 6,8 для RLSOld. Это вполне коррелирует с наличием операторов вида spool в планах запросов.

Также во время выполнения вырос показатель Page writes/sec (голубая линия), для RLSOld до 3,2 тыс, для RLSNew до 2,8 тыс. При выполнении в RLSOld показатель plan cache hit ratio упал с ~ 93 до 69.

Выборка из регистра накопления «Запасы» (первые 45 строк)

RLSOld — длительность 422972 мкс ~ 0,42 сек.

RLSNew — длительность 159879 мкс ~ 0,16 сек.

Планы довольно похожи на предыдущий вариант, за исключением того, что в плане RLSOld теперь нет оператора Index Spool, но оператор Row Count Spool по-прежнему присутствует.

По системному монитору ситуация похожая, только нет падения Cache hit ratio, при этом есть некоторый скачок счетчика Page reads/sec в начале выполнения запросов RLSNew.

Комплексный тест на запись (100 документов)

Чтобы установить причину увеличения времени RLSNew в тестах записи — запустим создание и проведение 100 документов, с одновременным включением замера «1С», ТЖ и мониторингом perfmon.

Общее время выполнения

• RLSOld = 136456 мс ~136 с.
• RLSNew = 150706 мс ~150 с.
• разница 14,25 с., RLSNew больше на 10,44%

Замер производительности «1С»

При сопоставлении замеров «1С» было обнаружено, что некоторые строки RLSNew не найдены в замере RLSOld, у них есть общая черта — все они из общего модуля «УправлениеДоступом
Служебный», суммарная длительность = 6,65 сек. (что составляет 4,87% от длительности в RLSOld).

Технологический журнал

Проведем анализ событий ТЖ CALL/SCALL, SDBL и DBMSSQL. Посчитаем общую длительность и количество событий. Для событий SDBL и DBMSSQL дополнительно сделаем выборки:

• по наличию названия модуля «УправлениеДоступом
  Служебный», строки с которым мы обнаружили в замере производительности «1С»;
• по наличию названий таблиц SQL блоков RLS старого и нового.

Полученные результаты сведены в таблицу:

Обзор:

• Замеры по событиям CALL в общем совпадают с замерами времени.
• Суммы SDBL «зашкаливают», это может быть объяснено вложенными и параллельными событиям, в данном ключе общая сумма не показательна, но можно заметить, что событий в RLSNew больше.
• Запросы, содержащие в себе имена таблиц блоков RLS в RLSNew суммарно выполняются на 2,74 сек. меньше, чем в RLSOld, при этом количество самих событий больше.

Системный монитор производительности

Посмотрим какое влияние на счетчики производительности оказало проведение документов в RLSOld и RLSNew.

Почти все счетчики сопоставимы в обеих базах, однако есть несколько по которым видны отличия:

• Buffer manager:Page reads/sec (на графике зеленая линия) — при проведении документов в RLSOld показатель поднимался до значения 6,4, в RLSNew оставался на 0. К росту взаимодействия с буферным кэшем вероятнее всего также приводят неоптимальные планы запроса.
• Avg. Disk Queue Length (E:) (фиолетовая линия) — в RLSOld очередь к диску была в пределах 2,7, в RLSNew она достигала значения 7,5. Т. к. на диске E находятся файлы обеих баз данных, рост показателя означает более интенсивную работу с данными базы на диске.
• Plan cache:Cache hit ratio (красная линия) — наблюдается некоторое падение с 91 до 71 пункта в последней трети выполнения RLSNew.

Выводы

В данной статье были рассмотрены вопросы перехода на новую систему RLS и её архитектуры, а также различные сравнительные показатели, что позволило выявить плюсы и минусы обеих систем.

Можно утверждать, что использование ключей доступа в новой RLS позволяет планировщику запросов MS SQL строить более оптимальные планы, а связь по ссылке дает возможность всегда использовать кластерный индекс. Что в конечном итоге даёт значительный прирост скорости при чтении данных. В то же время новая система имеет замедление при записи, т. к. требует некоторых ресурсов для актуализации ключей доступа.

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

Важно!

В настоящий момент существуют жалобы, связанные со значительным замедлением работы системы на новой RLS. Как было замечено в статье, такая проблема может наблюдаться в устаревшей версии блока. Если после перехода на новую систему RLS вы замечаете существенное замедление ключевых операций, снимите ТЖ на предмет долгих событий SDBL и проверьте версию БСП.

Тему замедления открытия форм в «1С» из-за RLS мы уже поднимали ранее в статье «Неожиданная причина долгого открытия формы в «1С»». Рекомендуем её тем, кому интересна взаимосвязь общей производительности и RLS.