УТ 11: Влияние количества ролей, назначенных пользователю, на скорость его работы в системе
Всем известно, что в типовом решении УТ 11 применена новая концепция разграничения прав доступа. А именно, в конфигурации создано большое количество ролей, каждая из которых определяет доступ к одному или нескольким объектам, далее, уже в пользовательской части, роли объединяются в профили, профили назначаются группам доступа, пользователи включаются в группы. В результате у пользователя появляется большое количество микро — ролей, речь может идти о сотнях, так как в типовой УТ 11 более 300 ролей. Удобно это или нет с точки зрения управления и поддержки, это вопрос отдельный и наверное спорный. А как наличие большого количества ролей влияет на производительность? В публикации представлены результаты проведенного мной эксперимента.
- Описание
- Подробнее
Описание
Эксперимент заранее не готовился. Ко мне обратились пользователи с вопросом медленной работы (порой зависания) списка справочника "Партнеры". Запустил под собой, проверил — все нормально, никаких зависаний нет. Запустил (на той же машине) под пользователем, который ко мне обратился — действительно список тормозит, причем только при прокрутке стрелками с клавиатуры, но не мышкой. Быстро понял в чем дело — в ПриАктивизацииСтроки происходит получение дополнительной информации по партнеру. Что может быть причиной? Смотрю права — у пользователя назначено более сотни ролей, у меня две (Полные права, Администратор системы). Добавляю пользователю роль "Полные права", проблема остается — список торомозит. Убираю у пользователя все кроме полных прав — проблема торможения списка уходит.
Вывод — большое количество ролей замедляет работу пользователя, что в общем то предсказуемо, но в данном случае подтверждено экспериментально.
Привожу результаты замеров производительности (приведены строки кода и время их выполнения для описываемых выше случаев):
Если НЕ ЗначениеЗаполнено(Партнер) ИЛИ Партнер.ЭтоГруппа Тогда
0,0149994897959184 — "много" ролей
0,0028094977973568 — "мало" ролей
Время выполнения различается на порядок!
Результат = Запрос.Выполнить();
0,0136426805555556 — "много" ролей
0,0107065418502203 — "мало" ролей
Контакты = ***КлиентСервер.ПолучитьДопИнфПоПартнеру(Элементы.Список.ТекущаяСтрока);
0,0107463741496599 — "много" ролей
0,0096472290748899 — "мало" ролей
Из замеров видно, что существенные различия во времени исполнения дает строка кода:
Если НЕ ЗначениеЗаполнено(Партнер) ИЛИ Партнер.ЭтоГруппа Тогда
Разбив строку условия на 2 отдельных условия и замерив время, выяснилось, что критичной является часть условия "Партнер.ЭтоГруппа", что логично, так как здесь происходит обращение к БД. Влияния количества ролей на время выполнения другой части условия — НЕ ЗначениеЗаполнено(Партнер), не выявлено.
На этом эксперимент не закончился. Я решил исследовать характер обнаруженной зависимости.
Далее я вернул пользователю исходные роли, добавил роль "Полные права" и стал последовательно удалять по 20 ролей (роли удалялись подряд по списку, роль "Полные права" не удалялась), делая замеры по строке с наибольшей разницей во времени выполнения на каждом из этапов. Результаты представлены ниже.
Строка кода, по которой проводились замеры:
Если НЕ ЗначениеЗаполнено(Партнер) ИЛИ Партнер.ЭтоГруппа Тогда
Результаты замеров представлены на графике:
Из графика видно, что, с учетом неизбежных погрешностей измерений, зависимость линейная.
Выявив характер зависимости, нужно было устранить влияние данного кода на работу списка.
Для этого код был выделен в отдельную процедуру, а в "ПриАктивацииСтроки" вместо него добавлен вызов обработчика ожидания:
&НаКлиенте
Процедура СписокПриАктивизацииСтроки(Элемент)
ПодключитьОбработчикОжидания("ВывестиДопИнфоПоПартнеру",0.2,Истина);
КонецПроцедуры
&НаКлиенте
Процедура ВывестиДопИнфоПоПартнеру()
Контакты = ***КлиентСервер.ПолучитьДопИнфПоПартнеру(Элементы.Список.ТекущаяСтрока);
КонецПроцедуры Таким образом влияние времени выполнения данного кода на скорость прокрутки списка было исключено.
Это решение подсказано в комментариях к начальной версии данной публикации участником nixel , за что ему огромное спасибо.
Данная публикация является логическим продолжением другой моей публикации, связанной со скоростью работы списков —
УТ 11: Ускоряем форму подбора номенклатуры , в которой предлагается решение вопроса ускорения работы списка путем изменения его запроса. Но, как выясняется, проблема может лежать и в совершенно другой плоскости.
Спасибо всем, кто высказал дельные замечания в комментариях, что позволило дополнить публикацию.
P.S.
26/03/2021
Проблема до сих пор не решена, рекомендую ознакомиться с публикацией //sale.itcity.ru/1c/articles/1409398/, посвященной проблемам производительности, в ней влияние количества ролей на производительность описано в разделе "Первая проблема".
