Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Performance of Group Searches

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Performance of Group Searches

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Shilen Patel <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] Performance of Group Searches
  • Date: Fri, 19 Oct 2007 15:07:02 +0100

--On 19 October 2007 09:22 -0400 Shilen Patel

After the modifications, in the cases where a non-GrouperSystem session
is created, about 75 percent of the time is actually spent on privilege
checking. I haven't yet looked for performance improvements in this
area. I've also noticed that the Grouper UI also does some privilege
checking during group searches, but I don't understand why. Shouldn't
this already be taken care of in the API? Gary can you comment on this?
The API checks that the user has VIEW privilege. Depending on the
browse mode you are in when you search I need to do further checks -
ADMIN or UPDATE for Manage groups, OPTIN for Join groups. In principle
we could extend the API interfaces to pass in the privileges so the
API can do all the checks - this is effectively the approach we were
trying for GRP-7.

Since the API already does the VIEW privilege check, can that be taken
out of the UI?
I think the only extraneous checks are done in 'All groups'. Back in 1.1, the API wasn't filtering by 'canView'. I'm actually testing for any Access privilege, but I needn't check any. Manage and Join still require their checks

I wonder whether the privilege checks should be done on the final
resultset after all the search filters have been resolved. Each search
filter may return a lot of results, but ANDed searches may cause many
to be discarded.

That's a great suggestion given how expensive the privilege checks are.
I'll look into that.

So I've made 3 primary modifications to get the performance results
described above.

1. Using ehcache and adding a new cache type in grouper.ehcache.xml,
I've adding caching to Member objects in GrouperAccessAdapter. 2. The
next modification is related to scoping the results. To determine if a
group or a stem (X) is a child of another stem (Y), the API currently
does some recursive checks up the hierarchy of X to see if Y is found.
Instead I made a modification to just check the object names. If the
name of X starts with the name of Y, then X is a child of Y.
Could this be worked into the query itself rather than iterating
through the results and doing comparisons?

Yes, it should be possible, however it would require changes to the API,
which I'm not sure should be done in a minor release. Either way, I
wouldn't expect much difference in performance. Thoughts?
Fair enough. Given we are feeling our way around the API I agree it is best to avoid significant changes where possible. In the longer run, if we are returning groups with attributes, adapting the SQL should result in less data transfer and object creation.

GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page