Subject: Grouper Developers Forum
- 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
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 checksAfter the modifications, in the cases where a non-GrouperSystem sessionThe API checks that the user has VIEW privilege. Depending on the
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?
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?
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.
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.
Could this be worked into the query itself rather than iterating
So I've made 3 primary modifications to get the performance results
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.
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?
GW Brown, Information Systems and Computing
- Performance of Group Searches, Shilen Patel, 10/18/2007
- Re: [grouper-dev] Performance of Group Searches, Tom Barton, 10/18/2007
- Re: [grouper-dev] Performance of Group Searches, GW Brown, Information Systems and Computing, 10/19/2007
Archive powered by MHonArc 2.6.16.