Hi,
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
ValueSerializer.
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
www.iktek.com
directory.apache.org
