Subject: Grouper Developers Forum
- From: Chad La Joie <>
- Subject: Re: [grouper-dev] Update: Subject API Slowness
- Date: Tue, 03 Oct 2006 18:35:23 -0400
- Organization: OIS - Middleware
I'm in the same boat Chris is in, and I'll offer one other suggestion that he didn't.
Consider setting up a second level cache with Hibernate. By default Hibernate keeps a Hibernate session scoped cache so repeated queries within that Hibernate session are pulled from cache first. Unless you, or the grouper folks, have specifically done other that session is closed, at latest, at the end of each HTTP request.
A second level hibernate cache keeps the information around between requests. Configuring it might save you a whole lot of those DB calls, and should help even if the paging mechanism doesn't support Hibernates paging API. Here's some info on it.
Mark Weber wrote:
Issue #1 (UI related)
One inefficiency/bug I want to point out with the UI and how it paginates result sets. If I am displaying the members of a group with a given privilege and there are 1,000 members in that group the UI displays 10/25/50/100 results at a time. However, for each new page request it re-requests the entire result set.
I think this is incorrect because new members may show up in between page requests and cause erroneous or confusing results between page requests. (i.e. they may see the same person on page 1 as they do on page 2 depending on the quantity of changes between page requests)
It's inefficient because in the case of 1000 members, at 50 results per page, it produces about 20,000 queries before I reach the last page.
If it's going to capture the entire result set it ought to store it, sort it and paginate it. And it should also allow for the user to "refresh" the results (thus implying the results are point-in-time)...IMHO.
Issue #2 (Back-end)
My trials led me to Hibernate's front door and our DBA is out this week so we're having trouble getting some hard numbers. But something looks askew. I thought it might be something with Oracle or something 10g specific?? I analyzed the tables tried adding different indexes etc... nothing made a dent. Next week we will be able to see specific activity for a given connection alongside the SQL it's attempting to execute.
So, in the meantime, I decided to switch out back-ends and use MySQL on localhost. Page loads for displaying privilegee's (50 members) went from 124 seconds down to 23 seconds. Better, but not yet acceptable. The fact that it's on localhost is probably the reason for the speed increase.
I'm going to try creating different groups with different permissions to see if I can spot something obvious. Maybe it's just having trouble displaying a group where every member has every privilege??
Chad La Joie 2052-C Harris Bldg
- Update: Subject API Slowness, Mark Weber, 10/03/2006
- Re: [grouper-dev] Update: Subject API Slowness, Chris Hyzer, 10/03/2006
- Re: [grouper-dev] Update: Subject API Slowness, Chad La Joie, 10/03/2006
- Re: [grouper-dev] Update: Subject API Slowness, GW Brown, Information Systems and Computing, 10/04/2006
Archive powered by MHonArc 2.6.16.