Grouper Developers Forum

[Chris Hyzer <>]

I havent had great success with the second level caching.  We run in a 
clustered env, in which case you would need a clustered cache, which is 
more complexity than its worth for us.  Is grouper assumed not to run in 
a clustered or load balanced env?  Also the hibernate second level 
caching caches objects by id and some queries.  If it is a one to many, 
then it cant cache by id.  Cached id is only for one to ones and many to 
ones (and querying by id).  Anyways, if there are thousands of queries 
for a screen with 50 rows, (or thousands of results in a resultset), 
then that is the problem.  For us, each simple oracle query takes 15-45 
millis, so if there are 1000, that is your 30 seconds right there.  
There should not be that many queries or results.  Either lazy loading 
can help, or properly using Hibernate's paging, or eager fetching, 
(outerjoining hasnt helped us, but is available) or all of the above.  
This is a very common problem with Hibernate... the app works perfectly 
in an env with a small database (or a local mysql db), and then when 
moving to a large database, these problems surface, and it is can be too 
late to make major (cheap) design decisions / changes...

The good news is that simple screens with recordsets from queries can be 
tuned (hopefully easily), and p6spy helps.  If there are report type 
screens where all records in a table need to be touched to process the 
report, then those are harder.  Thats where the JDBC (not hibernate) 
comes in, or hibernate projections, and possible strategies like 
emailing the user when the report is ready, or using a DB language like 
plsql (last resort? :) ).

Chris

Tom Barton wrote:

> The grouper api uses ehcache, and there've been some additional 
> optional caching capabilities introduced in HEAD since the 1.0 
> release. However, we haven't done thorough benchmarking, and what 
> little there is indicates mixed results to overall performance 
> depending on the backend database and query types.
>
> Tom
>
> Chad La Joie wrote:
>
> > 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.
> >
> > http://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#performance-cache