Grouper Developers Forum

["Michael R. Gettes" <>]

On Oct 19, 2007, at 15:05, Shilen Patel wrote:
> Tom Barton wrote:
> > > > I can't think of a downside to pre-fetching group attributes.
> > Beyond the space they take up, compared to a list of UUIDs. So  
> > this is a clear space/time trade-off. Could you arrange to observe  
> > jvm memory usage with a search that nets an even larger number of  
> > groups, try to get a sense of how much of a trade-off?
> The space can definitely add up as the number of groups returned  
> increases.  I performed a query for all of our approximately  
> 100,000 course groups.  The attributes are stored in HashMaps and  
> each HashMap has the 4 default key-value pairs for the names and  
> extensions of the group.  We don't have any additional attributes  
> for these course groups.  Anyways, the 100,000 HashMaps take up  
> about 22MB of space.

that's not much space!

> Since Michael brought up the comparison with LDAP, I just had a  
> thought.  When you perform an LDAP search you can provide a list of  
> attributes you want returned.  Has there been a consideration of  
> doing something similar with Group searches?  Just a thought....

This was part of what i was getting at with windowing on the call the  
other day.
Only get what you need.

> I also find it interesting that when I do the search that gives  
> 100,000 results, it takes 107 seconds when I use the default TTL  
> and memory values in the ehcache.xml file used by hibernate.   
> However, if I set the TTL and memory values to something that would  
> not be reached, the query takes 76 seconds.  31 seconds are spent  
> just flushing the cache.

Again, more lessons from the LDAP world - this is what LDAP tuning is  
all about - getting
the caching configured properly.  When you do - LDAP is blazingly fast!

/mrg