Grouper Developers Forum

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

--On 19 October 2007 09:22 -0400 Shilen Patel 
<>
 wrote:

> > > 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