Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Performance Issues

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Performance Issues

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Shilen Patel <>
  • Cc:
  • Subject: Re: [grouper-users] Performance Issues
  • Date: Wed, 13 Dec 2006 15:01:03 +0000

Responses below:

--On 13 December 2006 09:34 -0500 Shilen Patel

Responses below.

GW Brown, Information Systems and Computing wrote:
Hi Shilen,

Some responses and questions below.



--On 12 December 2006 15:17 -0500 Shilen Patel


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:

Manage Groups also calls

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

Have issues like these been addressed? Will they be resolved in a
version of Grouper? Any tips on how I can perform these operations
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.


-- Shilen

GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page