Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Update: Subject API Slowness

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Update: Subject API Slowness

Chronological Thread 
  • From: Chris Hyzer <>
  • Cc:
  • Subject: Re: [grouper-dev] Update: Subject API Slowness
  • Date: Tue, 03 Oct 2006 23:32:26 -0400

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? :) ).


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.


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.

Archive powered by MHonArc 2.6.16.

Top of Page