directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] Created: (DIRSERVER-918) Storing DN within attributes
Date Mon, 07 May 2007 19:38:15 GMT
Storing DN within attributes

                 Key: DIRSERVER-918
             Project: Directory ApacheDS
          Issue Type: Improvement
            Reporter: Emmanuel Lecharny

Attributes are stored into the Master table, and the associated DN is stored in another table.
If we store the LdapDN into an object containing also the Attributes, we will avoid many DN
parsing in the server : 
- the ReferralService tries to check if a DN is a referral, and has to parse the UpDN found
into the updn index
- the CollectiveAttributeService is also doing this normalization
- the DefaultAuthorizationService method isSearchable method normalize a DN which is stored
into the invocation stack : this DN has already been parsed
- the searchResponseIterator constructor parse the DN too.

All those useless normalization could be avoided if we store the normalized DN into the backend.
The gain is important : on a search test, search for 2705 entries, it cost 12% of all the
time spent into the server. This is around 4 times the initial DN parsing cost (in the codec).

Now, if we store the normalized form, we will have to pay a price for it : more time to deserialize
this added element, which is one of the most costly operation (15% of all the time). 

Another option could be to parse this updn only once, and to set it into the searchResult
object which is created.

As we are using the javax.naming.Searchresult object, which stores the DN as a String, we
will then have to create a new class to handle a LdapDN instead of a String.

The expected gain should be around 10%, which is far from being negligible.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message