УТ 11: Влияние количества ролей, назначенных пользователю, на скорость его работы в системе

Опубликовал Сергей Царегородцев (TSSV) в раздел Администрирование - Оптимизация БД (HighLoad)

Всем известно, что в типовом решении УТ 11 применена новая концепция разграничения прав доступа. А именно, в конфигурации создано большое количество ролей, каждая из которых определяет доступ к одному или нескольким объектам, далее, уже в пользовательской части, роли объединяются в профили, профили назначаются группам доступа, пользователи включаются в группы. В результате у пользователя появляется большое количество микро - ролей, речь может идти о сотнях, так как в типовой УТ 11 более 300 ролей. Удобно это или нет с точки зрения управления и поддержки, это вопрос отдельный и наверное спорный. А как наличие большого количества ролей влияет на производительность? В публикации представлены результаты проведенного мной эксперимента.

Эксперимент заранее не готовился. Ко мне обратились пользователи с вопросом медленной работы (порой зависания) списка справочника "Партнеры". Запустил под собой, проверил - все нормально, никаких зависаний нет. Запустил (на той же машине) под пользователем, который ко мне обратился - действительно список тормозит, причем только при прокрутке стрелками с клавиатуры, но не мышкой. Быстро понял в чем дело - в ПриАктивизацииСтроки происходит получение дополнительной информации по партнеру. Что может быть причиной? Смотрю права - у пользователя назначено более сотни ролей, у меня две (Полные права, Администратор системы). Добавляю пользователю роль "Полные права", проблема остается - список торомозит. Убираю у пользователя все кроме полных прав - проблема торможения списка уходит.

Вывод - большое количество ролей замедляет работу пользователя, что в общем то предсказуемо, но в данном случае подтверждено экспериментально.

Привожу результаты замеров производительности (приведены строки кода и время их выполнения для описываемых выше случаев):

Если НЕ ЗначениеЗаполнено(Партнер) ИЛИ Партнер.ЭтоГруппа Тогда
0,0149994897959184  - "много" ролей
0,0028094977973568  - "мало" ролей

Время выполнения различается на порядок!

 Результат = Запрос.Выполнить();
0,0136426805555556 - "много" ролей
0,0107065418502203 - "мало" ролей

Контакты = ***КлиентСервер.ПолучитьДопИнфПоПартнеру(Элементы.Список.ТекущаяСтрока); 
0,0107463741496599 - "много" ролей
0,0096472290748899 - "мало" ролей

Из замеров видно, что существенные различия во времени исполнения дает строка кода:
Если НЕ ЗначениеЗаполнено(Партнер) ИЛИ Партнер.ЭтоГруппа Тогда

Разбив строку условия на 2 отдельных условия и замерив время, выяснилось, что критичной является часть условия "Партнер.ЭтоГруппа", что логично, так как здесь происходит обращение к БД. Влияния количества ролей на время выполнения другой части условия - НЕ ЗначениеЗаполнено(Партнер), не выявлено.

На этом эксперимент не закончился. Я решил исследовать характер обнаруженной зависимости.
Далее я вернул пользователю исходные роли, добавил роль "Полные права" и стал последовательно удалять по 20 ролей (роли удалялись подряд по списку, роль "Полные права" не удалялась), делая замеры по строке с наибольшей разницей во времени выполнения на каждом из этапов. Результаты представлены ниже.

Строка кода, по которой проводились замеры:
Если НЕ ЗначениеЗаполнено(Партнер) ИЛИ Партнер.ЭтоГруппа Тогда

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

Выявив характер зависимости, нужно было устранить влияние данного кода на работу списка.
Для этого код был выделен в отдельную процедуру, а в "ПриАктивацииСтроки" вместо него добавлен вызов обработчика ожидания:
В 

&НаКлиенте
Процедура СписокПриАктивизацииСтроки(Элемент)

   ПодключитьОбработчикОжидания("ВывестиДопИнфоПоПартнеру",0.2,Истина);

КонецПроцедуры

&НаКлиенте
Процедура ВывестиДопИнфоПоПартнеру() 
 
    Контакты = ***КлиентСервер.ПолучитьДопИнфПоПартнеру(Элементы.Список.ТекущаяСтрока); 

КонецПроцедуры 



Таким образом влияние времени выполнения данного кода на скорость прокрутки списка было исключено.

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

Данная публикация является логическим продолжением другой моей публикации, связанной со скоростью работы списков -
УТ 11: Ускоряем форму подбора номенклатуры , в которой предлагается решение вопроса ускорения работы списка путем изменения его запроса. Но, как выясняется, проблема может лежать и в совершенно другой плоскости.

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

P.S.

07.02.2016

В описании изменений релиза 8.3.7.1845 платформы от 30.12.15, в разделе "Оптимизация" есть информация о том, что имевшая место существенная зависимость времени выполнения запросов от количества ролей назначенных пользователю была устранена. В частности говорится, что запросы для пользователей с неполными правами выполнялись недостаточно быстро - время выполнения запроса существенно зависело от количества ролей, назначенных пользователю. В результате было оптимизировано выполнение запросов для пользователей с неполными правами, с использованием ограничений доступа к данным, при большом количестве ролей и теперь время выполнения запроса не имеет существенной зависимости от количества ролей, назначенных пользователю.

Подробнее здесь:

Технологическая платформа 8.3. Версия 8.3.7.1845. Список изменений и порядок обновления

См. также

Комментарии
1. Дмитрий Елисеев (w-divin) 03.03.14 16:57 Сейчас в теме
Интересно, как поведет себя замер, если конструкцию "НЕ ЗначениеЗаполнено(Партнер)" заменить на "Партнер <> Справочники.Партнеры.ПустаяСсылка()" ? Может в данном конкретном случае такое влияние оказывает именно проверка на заполненность? Ведь не зря же в типовых конфигурациях пишут функцию проверки заполненности именно сравнением с пустым значением типа... Вот - нашел на скорую руку:
	Если Организация = Неопределено ИЛИ Организация = РегламентированнаяОтчетностьКлиентСервер.ПустоеЗначениеТипа("СправочникСсылка.Организации") Тогда
		Возврат Новый Структура;
	КонецЕсли;

Функция ПустоеЗначениеТипа(ЗаданныйТип) Экспорт

	Если ЗаданныйТип = Тип("Число") Тогда
		Возврат 0;

	ИначеЕсли ЗаданныйТип = Тип("Строка") Тогда
		Возврат "";

	ИначеЕсли ЗаданныйТип = Тип("Дата") Тогда
		Возврат '00010101000000';

	ИначеЕсли ЗаданныйТип = Тип("Булево") Тогда
		Возврат Ложь;

	Иначе
		Возврат Новый (ЗаданныйТип);

	КонецЕсли;

КонецФункции

...Показать Скрыть
2. Александр Капустин (kapustinag) 03.03.14 16:57 Сейчас в теме
Лишнее подтверждение тому, что разработчики типового решения озабочены чем угодно, но только не производительностью работы системы, и не проводят тестирование должным образом.
На УПП 1.3, при гораздо меньшем количестве ролей (не сотни, а "всего" десятки), тоже заметно замедление работы, если у пользователя много ролей. А в типовых ролях УПП и не получается дать пользователю одну-две роли.
McSim; zabaluev; POLGA; TSSV; +4 Ответить 1
3. Дмитрий Елисеев (w-divin) 03.03.14 17:00 Сейчас в теме
(2) kapustinag, разработчики типовых решений озабочены оменно типизацией своего решения. а для ускорения работы есть другие специалисты ))) чем бы вы зарабатывали, если бы типовые решения были идеальными?
4. Анатолий Бритько (headMade) 131 03.03.14 19:05 Сейчас в теме
5. Tsaregorodtsev (TSSV) 03.03.14 23:11 Сейчас в теме
(4) headMade, RLS не используется, включение / выключение настройки в "Ограничивать доступ на уровне записей" в БД на результат теста не влияет - проверил.
6. Tsaregorodtsev (TSSV) 03.03.14 23:31 Сейчас в теме
(1) w-divin, Торможение вызывает Партнер.ЭтоГруппа - разбил условие на 2 и проверил, вот что получилось:
ОбщийМодуль.***КлиентСервер.Модуль 1 561 Если Партнер.ЭтоГруппа Тогда 144 2,988937 23,43,
то есть 2,988937 / 144 = 0,0207565069444444
а строкой ЗначениеЗаполнено(Партнер) вообще можно пренебречь:
ОбщийМодуль.***КлиентСервер.Модуль 1 558 Если НЕ ЗначениеЗаполнено(Партнер) Тогда 144 0,000680 0,01
то есть 0,000680 / 144 = 4,722222222222222e-6 :)
7. Дмитрий Елисеев (w-divin) 04.03.14 13:48 Сейчас в теме
(6) Tsaregorodtsev, мне к сожелению негде проверить влияние большого количества ролей - у меня их всего 18, но могу предложить заменить проблемный участок кода на:
ЭтоГруппа=ОбщегоНазначения.ПолучитьРеквизитОбъекта(Партнер, "ЭтоГруппа")

Функция ПолучитьРеквизитОбъекта(Ссылка, ИмяРеквизита) Экспорт
	
	ОбъектМетаданные = Ссылка.Метаданные();
	ИмяТаблицы = ОбъектМетаданные.ПолноеИмя();
	Запрос = Новый Запрос;
	Запрос.Текст = "
	|ВЫБРАТЬ РАЗРЕШЕННЫЕ " + ИмяРеквизита + " КАК " + ИмяРеквизита + " ИЗ " + ИмяТаблицы + "
	|ГДЕ Ссылка = &Ссылка";
	Запрос.УстановитьПараметр("Ссылка", Ссылка);
	Выборка = Запрос.Выполнить().Выбрать();
	Если Выборка.Следующий() Тогда
		Возврат Выборка[ИмяРеквизита];
	Иначе
		РеквизитМетаданные = ОбъектМетаданные.Реквизиты.Найти(ИмяРеквизита);
		Возврат РеквизитМетаданные.Тип.ПривестиЗначение();
	КонецЕсли;
		
КонецФункции //ПолучитьРеквизитОбъекта()

...Показать Скрыть

8. Tsaregorodtsev (TSSV) 04.03.14 14:19 Сейчас в теме
(7) w-divin, спасибо. Думаю общей рекомендацией в условиях большого количества ролей будет отказ от объектной модели доступа к данным в пользу табличной (запросы).
Мы у себя вообще решили отказаться от типового механизма ролей УТ 11 и формируем новый набор полноценных ролей как именно ролей, а не непонятно чего. И здесь вопрос производительности на самом деле вторичен, но как дополнительный фактор тоже учитывался при принятии решения о смене концепции работы с правами.
9. Антон Стеклов (asved.ru) 31 05.03.14 06:39 Сейчас в теме
Ладно, ключевую функцию мы нашли: тормозит ЭтоГруппа().

Встают вопросы:
1) Как выполняется функция и где возникают тормоза: на 1С или на СУБД?
2) При чем тут роли?
3)
RLS не используется, включение / выключение настройки в "Ограничивать доступ на уровне записей" в БД на результат теста не влияет - проверил

Работа RLS проверяется не включением-выключением, а просмотром текста запроса уровня СУБД в трассировке.

Ответы на эти вопросы можно получить сравнением трассировок (события batch complete, rpc complete, showplan xml) для случая с одной ролью и множеством ролей. Если трассировки идентичны - вопрос к разработчикам платформы. Иначе - причина будет видна из трассировок.

На самом деле виноваты именно RLS, т.к. проверка, а следует ли использовать RLS, производится, грубо говоря, внутри RLS-запроса. Учите матчасть.
ojiojiowka; Il; +2 Ответить 1
10. Tsaregorodtsev (TSSV) 05.03.14 07:21 Сейчас в теме
(9)asved.ru,
Работа RLS проверяется не включением-выключением, а просмотром текста запроса уровня СУБД в трассировке.

Ответы на эти вопросы можно получить сравнением трассировок (события batch complete, rpc complete, showplan xml) для случая с одной ролью и множеством ролей. Если трассировки идентичны - вопрос к разработчикам платформы. Иначе - причина будет видна из трассировок.

На самом деле виноваты именно RLS, т.к. проверка, а следует ли использовать RLS, производится, грубо говоря, внутри RLS-запроса. Учите матчасть.


Ну и что ты будешь делать после изучения запроса уровня СУБД? Свою платформу писать сядешь?
Изучи вопрос и напиши что у тебя получилось.
11. Виктор Лебедев (eeeio) 80 05.03.14 08:57 Сейчас в теме
Интересно, а включение привелегированного режима влияет на скорость?
12. Антон Стеклов (asved.ru) 31 05.03.14 08:57 Сейчас в теме
(10) Tsaregorodtsev, т.е. Вы желаете, чтобы я разобрался в Вашей проблеме и сформировал решение? Такие вещи, как правило, оплачиваются, и недешево.

Куда копать, если желаете разобраться в сути проблемы, я Вам подсказал. Остальное - Ваше дело.
13. Евгений К (rar_xxx) 20 05.03.14 09:45 Сейчас в теме
Я считаю что и роли и rls играют роль в скорости работы, но начинать заморачиваться надо только если данных реально много, все крутится на сервере 1с, sql сервер отдельно работает и сжатие базы, переиндексация, обновление статистики, наконец дефрагментация винта, ускорение в виде 10го рейда или 1го рейда из ssd винтов, не помогает.
От rls можно отказаться только если от вас не требуют чтобы все начальники отделов видели только продажи/контрагентов своего отдела, а менеджеры вообще только свои продажи/своих контрагентов. Все кто хает RLS предлагайте быструю реализацию данной задачи.

p/s Продажи в смысле не только документы РеализацияТоваровУслуг, а все данные базы видны только по списку разрешенных контрагентов, организаций, складов.
14. Виктор Лебедев (eeeio) 80 05.03.14 10:38 Сейчас в теме
(9) хорошее замечание. возможно имеет смысл вычистить все запросы из рлс и тормозов станет меньше?
15. Антон Стеклов (asved.ru) 31 05.03.14 11:07 Сейчас в теме
(13) rar_xxx, как-нибудь посмотрите в план запроса со сложным RLS - если сумеете не материться - Вы очень сдержанный человек.

Речь не о том, что RLS - плохо, речь о том, что не следует делать чрезмерно сложные RLS, т.к. это усложняет запрос и снижает устойчивость плана запроса, как следствие мы получаем падение и нестабильность производительности.
16. Антон Стеклов (asved.ru) 31 05.03.14 11:10 Сейчас в теме
(14) eeeio, проще создать новые агрегированные роли вообще без RLS, как указано в (8)
17. Артур Аюханов (artbear) 851 05.03.14 12:17 Сейчас в теме
ОФФ. Как теперь подписаться на ответы, не создав новое сообщение?
Подскажите кто-нибудь.
18. Tsaregorodtsev (TSSV) 05.03.14 16:49 Сейчас в теме
(12) asved.ru, Я возможно неправильно Вас понял, возможно Вы имели ввиду, что производительность снижается не столько из за большого количества ролей как такового, сколько из за факта наличия шаблонов ограничений в выбранных у пользователя типовых ролях УТ11 - мы ведь о ней сейчас говорим. Это на самом деле несложно проверить и без погружения в такие дебри, как анализ запросов на SQL сервере. Постараюсь это проделать и сообщу о результатах.
19. Tsaregorodtsev (TSSV) 05.03.14 17:23 Сейчас в теме
(12) asved.ru, Результаты замеров с учетом наличия в ролях пользователя роли с шаблоном ограничений RLS (само разграничение как я уже говорил в базе отключено):
Строка анализируемого кода:
Если НЕ ЗначениеЗаполнено(Партнер) ИЛИ Партнер.ЭтоГруппа Тогда
Результаты замеров:
Много ролей (> 100, в т.ч. с шаблонами RLS и без): 0,0210996291666667
Мало ролей (2 роли), все без без РЛС: 0,0036270839328537
Мало ролей плюс одна роль с шаблоном ограничений RLS (всего 3 роли): 0,0029737675070028

То есть, само наличие шаблона ограничений RLS в роли никакого влияния на быстродействие не оказывает ...
20. Антон Стеклов (asved.ru) 31 05.03.14 20:30 Сейчас в теме
(19) Tsaregorodtsev, а Вы уверены, что в одной из ролей с RLS нет шаблона, по которому платформа, к примеру, строит запрос, сваливающийся в table scan вследствие отсутствия подходящего индекса или банальной ошибки разработчика, или в nested loops? Вы думаете, разработкой типовых конфигураций исключительно ЭТВ занимаются?
И даже если бы это было так - Всего ж не рассчитаешь! ©Падал прошлогодний снег

Повторяю: смотрите план запроса. Сопоставив таблицы БД, на которых выполняются проблемные операции, с метаданными, Вы определите примерный вид RLS-ограничения. А потом ищите его в шаблонах.
Если у нас просто слишком много RLS, и запрос проседает на соединениях с подзапросами, это тоже видно по плану запроса.

Вообще на тему анализа проблем производительности на днях книжка вышла: http://v8.1c.ru/metod/books/book.jsp?id=452
Сам еще не читал, но одобряю.
21. Антон Стеклов (asved.ru) 31 05.03.14 20:33 Сейчас в теме
PS если уж вам так неймется исследовать проблему по методологии "черного ящика" - забацайте 100 ролей без RLS. Поступок будет героический, я про него падаванам рассказывать буду.
22. Кирилл Карцев (Ворчун) 8 05.03.14 22:49 Сейчас в теме
Универсальность программного решения всегда приводит к усложнению и снижению быстродействия.
В принципе, что вам мешает создать одну роль для каждой должности, в которую слить все необходимые права?
И к тому же более правильная информация по быстродействию будет в том случае, если вы соберете детальную статистику работы в течении ходя бы полного рабочего дня. Например, соберете показания по APDEX. Ведь на временные показатели, что вы здесь привели, могло повлиять что угодно (например фоновое задание, или формирование проводок другим пользователем, сетевая нагрузка и пр.).
23. Tsaregorodtsev (TSSV) 05.03.14 23:18 Сейчас в теме
(22) Ворчун, Свой подход к решению обозначенной в публикации проблемы типовой УТ 11 я описал в (8), там как раз про одну роль для каждой должности. Цифры, что я здесь привел повторяются довольно стабильно, условия эксперимента описаны - выводы для себя делайте сами. Про сетевую нагрузку и пр. - спасибо, буду знать.
24. Tsaregorodtsev (TSSV) 05.03.14 23:27 Сейчас в теме
(21) asved.ru, Ваша склонность залезть поглубже в SQL (похоже по любому поводу) напомнила мне один хороший анекдот:
На улице недалеко друг от друга подрабатывают два гитариста - молодой и старый. Молодой музыкант показывает суперскоростную технику, "пилит" по всему грифу, сногсшибательно импровизирует, а старый скромно стоит в сторонке и извлекает вдумчиво пару-другую нот. Около молодого гитариста - никого, около старого - толпа народу. Один слушатель не выдержал, подошел к старому музыканту и спрашивает: "Как так получается, что тот молодой музыкант быстро играет, показывает фантастическую технику, и его никто не слушает, а вы спокойно играете несколько нот и вас слушает толпа народу?" Старый музыкант подумал и ответил: "Он только еще ищет свою ноту, а я уже нашел..."
25. Антон Стеклов (asved.ru) 31 06.03.14 06:50 Сейчас в теме
(24) Tsaregorodtsev, моя склонность залезть в SQL обоснована тем, что, как правило, большая часть проблем производительности 1С обусловлена проблемами производительности на уровне СУБД. А анализировать проблему нужно там, где она возникает.
ojiojiowka; +1 Ответить 1
26. Tsaregorodtsev (TSSV) 06.03.14 08:53 Сейчас в теме
(25) asved.ru, за книжку спасибо. А технологический журнал? Зачем же сразу в SQL?
27. Антон Стеклов (asved.ru) 31 06.03.14 10:10 Сейчас в теме
(26) Tsaregorodtsev, директива sqlplan сильно снижает производительность. Причем на DB2 и Oracle - до уровня известного пушного зверька.
Кроме того, графический план просто удобнее смотреть.
28. Никита Грызлов (nixel) 72 06.03.14 11:29 Сейчас в теме
Может просто стоит чуть-чуть дописать обработчик события ПриАктивизацииСтроки?
Если в этом обработчике есть как-то тяжелый код, то обычно этот код оборачивается в соседнюю процедуру, подключаемую как обработчик ожидания с задержкой, например, в секунду. Тогда при скроллинге списка с клавиатуры этот тяжелый код не успевает выполняться, так как постоянно срабатывает переподключение обработчика ожидания, а не заложенный в нем код. Если потребуется пример, могу предоставить, а так, думаю, сами разберетесь.
29. Tsaregorodtsev (TSSV) 06.03.14 16:00 Сейчас в теме
(28) nixel, идея понятна, спасибо!
30. Николай Терновой (ojiojiowka) 10.03.14 22:33 Сейчас в теме
Было бы достаточно странно, если бы RLS не снижала производительность, с учетом, что каждое условие - это дополнительный подзапрос к основному запросу. Смысла в статье такого рода не вижу. Автор мог бы подробно описать закономерность и принципы работы RLS, вместо того, чтобы писать кучу букв, содержащих только: RLS - отстой.
31. Tsaregorodtsev (TSSV) 11.03.14 09:05 Сейчас в теме
(30) ojiojiowka, По моему в Вашем комментарии немного смещены акценты относительно изложенного в публикации. Во первых - публикация не посвящена RLS, в ней про это нет ни слова.
Во вторых, публикация посвящена выявлению влияния количества ролей, назначенных пользователю, на производительность его работы. Среди множества ролей, назначенных тестовому пользователю (типовые роли УТ 11, здесь все прозрачно) изначально есть роли с шаблонами RLS (говорим о шаблонах, так как использование RLS в базе отключено), но далеко не все и более того, их "меньшинство". А вот линейный характер выявленной зависимости как раз опровергает утверждение (оно было высказано в комментариях) об определяющем значении в снижении производительности именно наличия в ролях шаблонов RLS. То есть, Ваш тезис, что статья это "наезд" на RLS - неверный. Скорей даже наоборот - влияния наличия в ролях шаблонов RLS на производительность не выявлено (!!!), но суть не в этом.
32. Яков А (qus-qus) 22 07.02.17 12:25 Сейчас в теме
Мы очень остро столкнулись с проблемой количества ролей на работе встроенной функции "ИзменитьРеквизиты" на какой версии платформы это происходило не скажу (года 1,5 назад), но из-за этой проблемы пришлось написать обработку распарсивающую набор ролей профиля и выдающую одну сводную роль. Правда потом 1С поправили эту проблему, но от сводных ролей мы так пока не отказались)

Ну и хочу на всякий случай напомнить, что в случае с наличием РЛС главное контролировать чтобы на один и тот же объект не было задано прав с разных ролей, если шаблоны в этих ролях одинаковы, то задублируются условия РЛС, что крайне негативно (не линейно) может сказаться на длительности запросов. Такие случаи встречаются и на типовых конфигурациях.