Hi Alex,
Alex Karasulu schrieb:
Stefan S.,
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.
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.
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.
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.
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.
Alex
Kind Regards,
Stefan Seelmann
