Alex Karasulu schrieb:no, we don't use a cache for Studio. I tried to use ehcache long time ago but it was really slow when it swaps entries to the disk and back.
Do we use a secondary cache for Studio? Just wondering because of the performance issues someone noted on the user list when dealing with a very large directory.
Today there we have the following:
- a HashMap<String, IEntry>: with the DN as key and the entry as value (IEntry is a Studio internal interface with some implementations)
- a HashMap<IEntry, AttributeInfo>: as soon as the attributes of an entry were loaded an AttributeInfo containing all attributes and other information is created and put to this map
- a hashMap<IEntry, ChildrenInfo>: as soon as child entries are loaded a ChildrenInfo containing all child entries is created and put to this map.
For sure, this does scale well. With the default VM parameters (64MB heap) you could load about 30,000 entries to get an OutOfMemory :-(((
I also think that the switch from the old DN/RDN implementation to the shared-ldap LdapDN/Rdn implementation costs some memory. We should consider to do some test for performance and memeory consumtion.
Yeah, that sounds great. You want me to look how the JDBM code works? I guess we will have some time at ApacheCon for that.
The idea occurred to me that the JDBM code for JdbmTable and JdbmIndex could potentially be used by Studio to help solve some of the caching problems. If this is something you think will help we can move this code into shared so both the server and Studio can leverage them.