12.05.2012, 16:50 | #1 |
Участник
|
Много групп прав и производительность...
AX 2009 RU7
Заметил такую вещь: если у пользователя большое количество групп прав (~ 300, это для теста) то форма "Клиенты" - "функции" - "сопоставление открытых проводок" открывается около минуты с дикомедленной прорисовкой каждой строчки. Если у этого же пользователя оставить одну группу прав - открывается на ура за 1 секунду. Та же пропорция по времени выполняется и в момент "пометки" строк. Пока такой глюк заметил только с этой формой, например те же формы "клиенты" и "заказы на продажу" открывается одинаково быстро. Форма "сопоставление открытых проводок" и связанные с ней таблицы не модифицированы. Есть ли в ax2009 такое правило: чем больше групп прав у пользователя тем ему хуже?=) |
|
12.05.2012, 17:49 | #2 |
Участник
|
Если на группах есть настройки RLS, то да - зависимость должна быть. В момент открытия формы будет "вычисляться" суммарный запрос, который должен быть отправлен на SQL-сервер. Ну а дальше смотрите итоговый план выполнения запроса. Возможно, после добавления всех RLS-ренджей существующие индексы будут уже не оптимальными.
|
|
12.05.2012, 18:09 | #3 |
Участник
|
Была ситуация на проекте, что на 300 юзеров приходилось 900 групп прав
Кончилось тем, что сочтя это бредом, волевым усилием перешли со схемы ролевых\функциональных групп на 1 юзер == 1 группа именованная Были написаны утилиты слияния кучи групп в 1 и копирования прав. Группы РЛС шли отдельно, в них был только РЛС настройки и включены таблицы, на которые он (тк без этих ключей, настройки РЛС просто игнорируются) Управляемость резко возросла. Чего и вам... очевидно, что 300 групп на одного юзера (пусть и на тесте) это много, тк будет гоняться цикл проверок, как написал _scorp_. И менеджерить такое админам - жесть! |
|
|
За это сообщение автора поблагодарили: RVS (1). |
12.05.2012, 18:17 | #4 |
Участник
|
Не обязательно в RLS дело. В некоторых местах системы в коде есть явная проверка на доступность какого-то действия (таблицы). В этот момент система "суммирует" права по всем группам и это может быть реально долго. Например, на форуме уже обсуждали проблему при работе с оповещениями - там при создании каждого оповещения явно проверяются права получателя на форму для просмотра источника оповещения. В итоге это может занимать такое время, что оповещения не будут успевать рассылаться за время выполнения пакетного задания, а далее по нарастающей вплоть до остановки системы оповещений в принципе.
__________________
Ivanhoe as is.. |
|
12.05.2012, 18:22 | #5 |
Участник
|
Насчет стратегии групп. Больше 5-10 групп на пользователя не приходилось делать. Как правило - одна группа с общими правами сотрудника, одна-две-три группы с функциональностью, две-три группы с RLS (не всегда используются). Если получается больше - нужно выделять более точечные роли.
В крайних случаях, действительно доходят до роли "МарияИвановнаПетрозаводск", но на на моих проектах такого ни разу не допускалось
__________________
Ivanhoe as is.. |
|
14.05.2012, 01:29 | #6 |
Сенбернар
|
Я бы думал так:
- ограничение прав есть нагрузка на систему. Полюбому. Она, перед тем, как что-то там показать, должна подумать - 'а можно?' Это занимает время. У вас, у меня, у Аксы. - 300 групп - это песня Господа, ГРУППА - это набор прав и обязанностей (это связано обычно, напрямую) пользователя. Сейлс, хуман, мастер цеха, наконец... бухгалтер... 300 - не бывает, или я чего-то не понимаю в этой жизни. Сухой остаток: посмотрите на то, как организованы эти группы. И зачем - именно так. Найдете много интересного, я знаю А Акса - всего лишь программа, хотя и хорошая. Она честно пытается сделать то, что ВЫ пытаетесь заставить ее делать. Вооот...
__________________
Best Regards, Roman |
|
14.05.2012, 10:07 | #7 |
Участник
|
В том то и дело, что никаких RLS.
300 групп - это сделал для теста, чтобы убедиться, что количество групп действительно влияет. В рабочей среде у пользователя 20-30 групп. Согласен, что не мало, но мы пошли правилу "минимально неделимый функционал" и так разбили группы. Какие варианты решения? только пересматривать количество групп? или можно сделать модификацию на данной форме? (ведь остальные работают нормально) |
|
14.05.2012, 10:40 | #8 |
Участник
|
В этой форме безумное количество вызовов changeCompany(), видимо с этим и связаны тормоза при большом количестве групп прав.
Посмотрите, какими-нибудь средствами, что "убивает систему", например, SQL-профайлером или мониторингом запросов, если это окажется changeCompany, то скорее скорее всего придется уменьшать количество групп, если у вас более одной компании, в другом случае можно подумать и об модификации и оптимизации запросов.
__________________
Sergey Nefedov |
|
14.05.2012, 12:00 | #9 |
Участник
|
Слышал от одного коллеги про подобный баг. Вроде бы баг даже зарегистрирован в MS. Возможно, это Ваш случай. Смысл в том, что если на форме используются данные из виртуальных компаний и на форме присутствуют дисплейные поля, то совместно с вызовом дисплейного метода идут запросы к таблице AccessRightsList. И запросы идут в бешеном количестве, что очень хорошо видно в профайлере.
Последний раз редактировалось _scorp_; 14.05.2012 в 12:37. |
|
14.05.2012, 13:11 | #10 |
Сенбернар
|
Цитата:
Цитата:
Думать... головой. Sorry for my English
__________________
Best Regards, Roman |
|
15.05.2012, 01:53 | #11 |
Участник
|
у нас Сопоставление открытых проводок и пометка тормозило при кол-ве групп порядка 100.
как выяснилось более критична была опция CrossCompanyAutoQuery на датасорсе - детально не исследовали, но судя по профайлеру уходила пачка запросов на все компании + AccessRightList. у себя отключили, потому как не используем сопоставления между компаниями - сразу стало все летать) Последний раз редактировалось vanokh; 15.05.2012 в 01:57. |
|
|
За это сообщение автора поблагодарили: Logger (3), lev (2), propeller (1). |
Теги |
права доступа, права доступа на уровне записей (rls), производительность, сопоставление |
|
|