DatabasePsmlManagerService

[Glenn Golden <gg...@umich.edu>]

I've got some changes to the DatabasePsmlManagerService to drastically
reduce the number of hits against the db, or, in other words, greatly
improve it's caching.

Currently, it is using a "WeakHashmap" to cache psml docs.  In my experience
with it, docs are rarely found in the cache.  They sometimes are, and I
think this is when there's an overlapping request for a doc or successive
doc requests without a garbage collect in between.   But usually, the cache
is empty.  This is consistent with my read of what a WeakHashmap does.

In addition, the profiler tries a series of locator combinations until a
page is found.  In my setup, it always tries three, and the third one finds
my psml doc.  These first two requests happen each time, even if the
successful one has been cached.

Here's my changes:

First, I use a Hashmap instead of a weak one.  Let it cache.  The class has
a thread which refreshes the cache from the db to handle changes made to the
db behind Jetspeed's back.

Second, I am caching failures as well as successes.  Those first two
locators will be found, and found as null, in the cache, so the db does not
have to be consulted each request, once we know they are NOT there.  These
will also be refreshed by the refreshing thread - left null or filled in.

The result is a significant reduction of db hits for pages when the
application has frequent requests for a page or many users using the same
page (my app does both!).

I'm happy to check this in, sharing the improvements.  Any comments?  Any
concerns?

Thanks!

- Glenn

--------------------------------------------
Glenn R. Golden, Systems Research Programmer 
University of Michigan School of Information
ggolden@umich.edu               734-615-1419
--------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: DatabasePsmlManagerService

[David Sean Taylor <da...@bluesunrise.com>]

> -----Original Message-----
> From: Glenn Golden [mailto:ggolden@umich.edu] 
> Sent: Saturday, June 29, 2002 6:45 PM
> To: Jetspeed-Dev (jetspeed-dev@jakarta.apache.org)
> Subject: DatabasePsmlManagerService
> 
> 
> I've got some changes to the DatabasePsmlManagerService to 
> drastically reduce the number of hits against the db, or, in 
> other words, greatly improve it's caching.
> 
> Currently, it is using a "WeakHashmap" to cache psml docs.  
> In my experience with it, docs are rarely found in the cache. 
>  They sometimes are, and I think this is when there's an 
> overlapping request for a doc or successive
> doc requests without a garbage collect in between.   But 
> usually, the cache
> is empty.  This is consistent with my read of what a WeakHashmap does.
> 
> In addition, the profiler tries a series of locator 
> combinations until a page is found.  In my setup, it always 
> tries three, and the third one finds my psml doc.  These 
> first two requests happen each time, even if the successful 
> one has been cached.
> 
> Here's my changes:
> 
> First, I use a Hashmap instead of a weak one.  Let it cache.  
> The class has a thread which refreshes the cache from the db 
> to handle changes made to the db behind Jetspeed's back.

+1 on replacing the WeakHashMap. I've experienced the same problem also
in the Castor impl.

The thread sounds ok, as long as you can configure how often it runs.
Did you use the Turbine's scheduler? Its dead easy to use and reliable.
The TurbineNonPersistentSchedulerService configures everything in the
TR.p, not in db.
I think in the long run I'd prefer something like JCS
http://jakarta.apache.org/turbine/jcs, but for now this will do fine.

> Second, I am caching failures as well as successes.  Those 

+1 Great, that's on my todo list.
Im also planning on caching misses in the Castor (default) impl

> first two locators will be found, and found as null, in the 
> cache, so the db does not have to be consulted each request, 
> once we know they are NOT there.  These will also be 
> refreshed by the refreshing thread - left null or filled in.
> 
> The result is a significant reduction of db hits for pages 
> when the application has frequent requests for a page or many 
> users using the same page (my app does both!).
> 
> I'm happy to check this in, sharing the improvements.  Any 
> comments?  Any concerns?
> 
Just that I hope you can get it in very soon if at all possible.
I'd like to propose that we do a release by the end of next week...


David

> Thanks!
> 
> - Glenn
> 
> --------------------------------------------
> Glenn R. Golden, Systems Research Programmer 
> University of Michigan School of Information
> ggolden@umich.edu               734-615-1419
> --------------------------------------------
> 
> --
> To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <ma...@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>