Another thing just popped into my head.

What if the DAS had a configuration option
telling ADS what forms to write entries in.

For instance sometimes the user will know
that they only want the normalized form
written...

Thoughts?

Thanks,
- Ole




Emmanuel Lecharny wrote:
Ole Ersoy a écrit :

What I mean by that is what is the minimum
size of an entry considering only the fixed parts
or the keys of the entry effectively + anything
else that is needed to manage the entry that has
to be stored in memory.

Then it's around 1kb. Of course, this is a rough estimation.

So what can be done to minimize the size?


Nothing.


So what that then means is that the structural component of
an entry is always minimized within ApacheDS?

well, the short answer is 'no'. As stated by alex, we should keep two forms : the user provided form, and the normalized form. For performance reasons, we should not compute the normalized form each time we do a search operation, this will kill the server. keep in mind that a ldap server is 99,99% read, and less tha 0,01write. So it definitively worth the price to spend a *lot* of time writing twice the data in to different forms than do a computation for each search. Adding entries in ADS is 10 to 20 times slower than reading them.


So when I'm using JNDI to update an attribute, and the
key of my Attribute is "com.example.blah.blah.blah.blah.blah.blahblah.blahhhhhhh.something"
ApacheDS takes that key and turns it into the shortest possible number
it can before storing it?

yes. We have the exact equivalence to "sequecnes" in oracle, and we use them to give a Long for each entry, and for each indexed attribute.


But is this really important ? Just think about the 80/20 rule

(and it's much closer to a 95/5) : 20 percent of all entries will be accessed 80% of time. A good cache will usually gives you the same result (or close to) as if you put everything in memory. This is very basic IT theory...


Yes - Totally - For search operations that type of tweaking is awesome
and effective. It applies to Supply Chain Applications some times, and other times all the data is fair game. For instance
the application might be calculating Optimal Inventory Figures for all
SKUs and and wants to do the run "Superfast", so it wants all the data
in memory.

Maybe in Supply Chain Apps. But a Ldap Server is totally different. Don't think like if you only have a hammer... In your case, Ldap being very fast, even compared to a RDBMS, it might be interesting to use i. But you should also consider other elements, like the cost of writing in it, and the cost of a traversal (doing a full scan).

Yes - I usually go for 1 first, then pump it up :-)
I like the band too.

I prefer dead kennedys (http://www.deadkennedys.com/), but I'm a psycho %-]

Emmanuel

Reply via email to