grouper-dev - RE: [grouper-dev] caching & ldappcng
Subject: Grouper Developers Forum
List archive
- From: Chris Hyzer <>
- To: Tom Zeller <>, Grouper Dev <>
- Subject: RE: [grouper-dev] caching & ldappcng
- Date: Fri, 25 Mar 2011 09:59:56 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
Are you saying that if a cache config in the xml files doesn't exist that
things should still work and it should just use the default cache config? So
that if people keep things as they are now, then everything will be the same.
But if they wipe out their xml files and just have a default config, that
all caches will use those default config settings?
Thanks,
Chris
-----Original Message-----
From:
[mailto:]
On Behalf Of Tom Zeller
Sent: Friday, March 25, 2011 1:15 AM
To: Grouper Dev
Subject: [grouper-dev] caching & ldappcng
Caching impacts ldappcng significantly. I had not investigated this before.
Our ehcache config files, ehcache.xml and grouper.ehcache.xml, are
daunting - so many caches to tune !
I wanted to cache "everything", so I decided ehcache.xml and
grouper.ehcache.xml should look like this :
<ehcache>
<defaultCache
maxElementsInMemory="500000"
eternal="false"
timeToIdleSeconds="120"
timeToLiveSeconds="120"
overflowToDisk="false"
/>
</ehcache>
Unfortunately, we sometimes hardcode ehcache parameters - which are
not overriden by the <defaultCache /> element.
So, adding a method to EhcacheController which uses <defaultCache/>
unless a configuration is specified :
public Cache getCacheWithDefaults(String name) {
this.initialize();
if (!this.mgr.cacheExists(name) ) {
mgr.addCache(name);
}
return mgr.getCache(name);
}
and calling this method in the constructor of CachingAccessResolver,
CachingAttrDefResolver, and CachingNamingResolver
public CachingAccessResolver(AccessResolver resolver) {
super(resolver);
this.cc = new EhcacheController();
// init cache
cc.getCacheWithDefaults(CACHE_HASPRIV);
}
means that it would be possible to configure all caches using <defaultCache/>.
I also wrote a helper method to display ehcache statistics :
2011-03-25 00:07:23,408: [Timer-3] INFO
edu.internet2.middleware.ldappc.spml.PSPCLI.run(157) - - End of
ldappc-ng execution : 36 ms
2011-03-25 00:07:23,411: [Timer-3] INFO
edu.internet2.middleware.ldappc.spml.PSPCLI.run(166) - -
cache hit ratio 75% 3 hits 1 miss :
edu.internet2.middleware.grouper.FieldFinder.fieldCache
cache hit ratio 56% 5 hits 4 miss :
edu.internet2.middleware.grouper.GroupTypeFinder.typeCache
cache hit ratio 50% 10 hits 10 miss :
edu.internet2.middleware.grouper.subj.CachingResolver.FindByIdentifier
cache hit ratio 50% 10 hits 10 miss : SpmlDataConnector
cache hit ratio 0% 0 hits 15 miss :
edu.internet2.middleware.grouper.Field
cache hit ratio 67% 2 hits 1 miss :
edu.internet2.middleware.grouper.Group
cache hit ratio 75% 39 hits 13 miss :
edu.internet2.middleware.grouper.Member
cache hit ratio 67% 2 hits 1 miss :
edu.internet2.middleware.grouper.Stem
If you read this far ...
Armed with such statistics and the ease of configuring one
<defaultCache />, I think deployers of ldappcng would have an easier
time tuning caching to meet their needs.
I have not committed anything yet, let me know what you think.
TomZ
- [grouper-dev] caching & ldappcng, Tom Zeller, 03/25/2011
- RE: [grouper-dev] caching & ldappcng, Chris Hyzer, 03/25/2011
- Re: [grouper-dev] caching & ldappcng, Tom Zeller, 03/25/2011
- RE: [grouper-dev] caching & ldappcng, Chris Hyzer, 03/25/2011
Archive powered by MHonArc 2.6.16.