Grouper Users - Open Discussion List

["GW Brown, Information Systems and Computing" <>]

Responses below:

--On 13 December 2006 09:34 -0500 Shilen Patel 
<>
 wrote:

> Responses below.
>
>
>
> GW Brown, Information Systems and Computing wrote:
> > Hi Shilen,
> >
> > Some responses and questions below.
> >
> > Regards,
> >
> > Gary
> >
> > --On 12 December 2006 15:17 -0500 Shilen Patel 
> > <>
> >  wrote:
> >
> > > Hello,
> > >
> > > 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".
> > Is 'Create Groups' similarly slow? Is searching slow?
>
> I can enter the "Create Groups" page quickly, but the search is slow
> depending on what I search.  I think if I search under a stem where the
> user has many memberships or privileges, the search will stall.
The UI does a general search and then tests each result i.e.
return (searchResult.hasStem(subj)|| searchResult.hasCreate(subj));

I need to add some flexibility in what is searchable for stems, but the 
best solution may be to have configurable search result size limits. If a 
search gives more results, the user would have to try a more specific 
search.

> > 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 of
> > > the groups, method calls like Member.hasRead() and Member.hasView() can
> > > take hours.
> > Granting 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
>
> In our scenario, the default read and view privileges are appropriate.
> Does any place in the UI call member.hasRead() or member.hasView() ?
I think the only place is the Subject Summary page where you can list 
groups or stems where a subject has a selected privilege.

If, as in your case, there are tens of thousands of results we need to cap 
the number that can be shown, and allow searching as a way of limiting the 
size of the result set
> > > 3.  I have an instance where a Group X has admin privileges to about
> > > 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?
> > As 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.
> >
> > 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?
>
> We have a root stem duke with 4 stems -- employees, students, oit, and
> siss.  The employees stem has 4 groups that contain about 80,000
> memberships.  The students stem also has 4 groups with about 20,000
> memberships.  The oit stem has about 50 small groups and 2 large groups.
> The two large groups are nested 4 levels under the top level oit stem.
> These two groups have large groups from the employees and students stems
> as members.  Finally, the siss group contains our class roster data with
> student, instructor, and TA groups for each class.  Except for one group,
> all groups in the siss stem are nested 7 levels deep.  The total number
> of memberships in the siss stem is about 230,000.  The exception group is
> a group that has admin privileges to all of the TA groups.  This is the
> Group X that I mentioned above.
I'll have a look at prototyping a method to answer:

does Stem S have any descendant Groups where Subject subj has a
privilege from [update, admin,...]

It looks like this could be answered quickly for your admin group members - 
but may be not so quickly for other subjects. The UI has a pluggable 
interface for browsing and searching, so it should be straightforward to 
come up with an alternative implementation, however, getting one that works 
for all Subjects may be trickier.
> Thanks,
>
> -- Shilen



----------------------
GW Brown, Information Systems and Computing