directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DIRSERVER-918) Storing DN within attributes
Date Wed, 26 May 2010 12:27:16 GMT

     [ https://issues.apache.org/jira/browse/DIRSERVER-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Emmanuel Lecharny updated DIRSERVER-918:
----------------------------------------

    Fix Version/s: 2.0.0-RC1
                       (was: 2.0.0)

Moved back to 2.0.0-RC1

> Storing DN within attributes
> ----------------------------
>
>                 Key: DIRSERVER-918
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-918
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>    Affects Versions: 1.5.0, 1.0.2
>            Reporter: Emmanuel Lecharny
>             Fix For: 2.0.0-RC1
>
>
> 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.


Mime
View raw message