directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [ApacheDS] [entryDn] We should add it! (was: Re: [ApacheDS] Poor man's cluster interceptor)
Date Tue, 24 Feb 2009 19:24:46 GMT
Alex Karasulu wrote:
> Might be a good idea to add this operational attribute as a virtual
> attribute to an entry when it is going out the door ONLY. 
We already have it. No need to add this attribute, we just have to get 
the DN from the entry we are manipulating.
>  We should do it
> like this because then we don't have to load up the entry from the backend
> when doing modDn operations.  At this point we're totally hosed on modDN
> because of the decision to include the DN in the entry.
> Incidentally I will have to veto any release that does not fix this problem:
> it's high priority IMO. 
I think you are fighting the wrong horse here. It's not a problem, it's 
an optimization.
> I warned about the performance issue it brings
> about. Howard Chu confirmed this and still it's the case. To see just load
> up a server with 1M user entries then try a modDN on ou=Users.  Do it on the
> server before this change and after it was introduced.  Seeing the
> difference will convince anyone.
I agree that for a user doing a moddn every minutes on a 10 million 
entires server, tat might be an issue. Now, considering that moddn is 
_by far_ not the most oftenly used operation on a LDAP server, I don't 
see where the problem is. In fact, I'm pretty sure that it cost the same 
to have the DN in the entry or not (or at least, it has the same cost, 
from the complexity theory pov). I will try to explain it once again :

1) you don't have the DN within the entry
- for EVERY search, you will have to fetch the entry and to fetch the 
DN, in two different tables.
- doing a moddn, you will have to update _all_ the DN which are impacted 
(one per moved entry)

2) you have the DN within the entry
- for EVERY search, you spare a fetch for the DN table
- doing a moddn, you will have to update _all_ the impacted entries - as 
they contains the UpDN and all the NormDN table
- incidentally, you don't have to deal with the UpDN table, as it's now 
useless (it's already present into the entry) : you can spare a table 
and an index. Not to be neglected.

We can discuss this again, I think there are pros and cons in both 
sides. But I'm pretty sure that (2) would be faster for 99% of the cases 
(ie, for a server where a moddn is not a frequent operation.).

I personally doubt that a serious LDAP admin will accept more than a few 
moddn per year. IMHO, this is typically something you do offline when 
reorganizing a base. I may be wrong, though.

I would suggest one thing : we have the Apache Conference in one month, 
a perfect place to discuss this point, as many of us will be there.

I remember having suggested last year that we could let the user decide 
: having the DN stored within the entry could be an option. It won't be 
such a pb to implement this in the server, now that everything is quite 
decoupled right now (we still have the UpDN table, and it's managed, 
plus we need the entryDN to be present, it's just a matter to inject it 
while fetching the entry, instead of deserializing it). So we didn't 
closed any door so far. Maybe a week of work to establish this dual mode.

But I'm ready to bet a bottle of good champagne that option (2) will 
bring better performance for mostly all the operations for an acceptable 
penalty when doing a moddn :)

cordialement, regards,
Emmanuel L├ęcharny

View raw message