You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2007/05/07 21:38:15 UTC
[jira] Created: (DIRSERVER-918) Storing DN within attributes
Storing DN within attributes
----------------------------
Key: DIRSERVER-918
URL: https://issues.apache.org/jira/browse/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.
[jira] Resolved: (DIRSERVER-918) Storing DN within attributes
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny resolved DIRSERVER-918.
-----------------------------------------
Resolution: Invalid
This has been implemented in the 1.5.5 versions, and we rollbacked it recently, as it makes the MODDN operation extremely costly.
> 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.
[jira] Closed: (DIRSERVER-918) Storing DN within attributes
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny closed DIRSERVER-918.
---------------------------------------
Invalid
> 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.
[jira] Updated: (DIRSERVER-918) Storing DN within attributes
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRSERVER-918:
----------------------------------------
Affects Version/s: 1.0.2
1.5.0
Fix Version/s: pre-2.0
Postponed to 2.0
> 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.0.2, 1.5.0
> Reporter: Emmanuel Lecharny
> Fix For: pre-2.0
>
>
> 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.
[jira] Updated: (DIRSERVER-918) Storing DN within attributes
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ 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.