grouper-users - Re: [grouper-users] Performance Issues
Subject: Grouper Users - Open Discussion List
List archive
- From: "GW Brown, Information Systems and Computing" <>
- To: Shilen Patel <>,
- Subject: Re: [grouper-users] Performance Issues
- Date: Wed, 13 Dec 2006 10:44:54 +0000
Hi Shilen,
Some responses and questions below.
Regards,
Gary
--On 12 December 2006 15:17 -0500 Shilen Patel
<>
wrote:
Hello,Is 'Create Groups' similarly slow? Is searching slow?
I have Grouper 1.1 installed with about 72,000 groups and 460,000
members. After adding all these groups and members, I've noticed
performance issues like the following:
1. In the Grouper UI, using the "Manage Groups" link stalls. However, I
have no problems using "All Groups".
Both options call:
member.hasAdmin()
member.hasUpdate()
Manage Groups also calls
member.hasStem()
member.hasCreate()
These calls are made so that the UI can filter out stems which don't have manageable groups. It would be possible to come up with a configuration setting which would avoid these calls - and so should perform as 'All Groups' does, however, you would be able to browse down dead ends.
blair: The UI would work OK if it were possible to ask:
does Stem S have any descendant Groups where Subject subj has a privilege from [update, admin,...]. This might not be straightforward to determine, but would avoid the member.has calls.
2. Since the ALL subject is granted read and view privileges to all ofGranting of read and view privileges to GrouperAll is optional and the default privileges granted configurable, but if it is appropriate to your scenario then we have to figure out what is reasonable behaviour when the number of groups returned is in the 1000's
the groups, method calls like Member.hasRead() and Member.hasView() can
take hours.
3. I have an instance where a Group X has admin privileges to aboutAs we get feedback from sites implementing Grouper in real world situations and with large repositories we will attempt to resolve the issues that come up. Those that are a barrier to uptake of the product are likely to be dealt with first. There is fairly limited experience of working with large repositories, and how Grouper and the UI perform may well vary according to how repositories are structured.
20,000 groups. It takes about an hour to add a member to Group X
because the new member is indirectly given admin privileges to the 20,000
groups.
Have issues like these been addressed? Will they be resolved in a future
version of Grouper? Any tips on how I can perform these operations
faster?
Would you be able to provide an overview of how your repository is structured? i.e. how many top level stems are there and how deep does the hierarchy go?
Thanks,
-- Shilen
----------------------
GW Brown, Information Systems and Computing
- Performance Issues, Shilen Patel, 12/12/2006
- Re: [grouper-users] Performance Issues, Tom Barton, 12/12/2006
- Re: [grouper-users] Performance Issues, Shilen Patel, 12/13/2006
- Re: [grouper-users] Performance Issues, GW Brown, Information Systems and Computing, 12/13/2006
- Re: [grouper-users] Performance Issues, Shilen Patel, 12/13/2006
- Re: [grouper-users] Performance Issues, GW Brown, Information Systems and Computing, 12/13/2006
- Re: [grouper-users] Performance Issues, Shilen Patel, 12/13/2006
- Re: [grouper-users] Performance Issues, blair christensen., 12/14/2006
- Re: [grouper-users] Performance Issues, Shilen Patel, 12/14/2006
- Re: [grouper-users] Performance Issues, Tom Barton, 12/12/2006
Archive powered by MHonArc 2.6.16.