directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject [DN] Serilaizing DN in the backend
Date Tue, 19 Feb 2008 11:14:44 GMT

while doing some basic performance tests, I found that DN handling (all 
the LdapDN methods gathered) represented around 32% of the time spent in 
the server.

Here are some of the numbers, for 20000 search requests :
- new LdapDN(bytes) + normalizing (20000 times): 10,8%. This is the 
original parsing done when the request is being decoded.
- new LdapDN(String) + normalizing (40000 times) : 20,2%. These are the 
parses done when reading DN index from the backend.

If we store DN as serialized DN and not as String, we will save a hell 
lot of time ! Some tests I did demonstrate that 
serializing/deserializing DN is 3 times faster than 
Serializing/Deserializing Strings + Parse String to DN + Normalizing DN. 
As we have some cache too, this may even be infinitely faster !

Now, the question is : how do we serialize LdapDN into the backend ? We 
have 2 index used to managed DNs : ndn and upDn (I don't think that upDn 
is usefull). If we can pass a serializer to those index, and use it, we 
are (almost) all done. We also have to provide some comparators which 
compares DN and not String.

That means :
 - define some DN serializer/deserialize (done)
 - define DN comparators (almost done)
 - modify the JdbmIndex API to be able to pass keySerializer and 

The last point is the missing part of the task.

Note : why is upDn index useless ? Because if we store a serialized 
LdapDN, then we have access to the UP form, and more than that, w will 
always work with normalized forms of DN, returning the UP form only when 
building the respons, which is easy, as we store the UP form into the 
seralized DN. This will also benefit to the Add request, as we won't 
have to uodate 2 index instead of one...

wdyt ?

cordialement, regards,
Emmanuel L├ęcharny

View raw message