Re: Shortcutting on a local server

["Booker C. Bense" <bbense@networking.stanford.edu>]

On Wed, 21 Jun 2000, Dave Steck wrote:

> Some interest has been expressed in the possibility of
> automatically shortcutting some steps when talking to a server on
> the same machine as the client.  Theoretically if a client is
> talking to a server hosted on the same machine, you'd like to
> avoid the protocol stack, SSL encoding, and perhaps the ber
> encoding.  The advantage is greatly increased performance.

- How do you know that? I think you're just speculating. 

> 
> Suppose you could determine the local machine issue at ldap_init()
> time.  If any of the host names was to the local machine, you
> automatically use it.  Although the spec says you should use the
> first one you can connect to, you would in general want to go to
> the local machine over another one.
> 
> There are many more issues, and the architecture of OpenLDAP may
> not lend itself easily to doing this.
> 
> I'm interested in some feedback.  Is this fundamentally a BAD
> idea, architectural nightmare, great if it can be done, etc.
> 

- I think it's way more work than it's worth. At stanford we've been
using ldap to route campus email for about 3 years now.  I have seen
no performance differences between local and remote or authenticated
vs. unauthenticated lookups. In fact, we have seperated the email and
ldap servers to improve the reliablity of the service. We are using
kerberos, not SSL. SSL has a higher overhead, but before you begin
this adventure, you should do some profiling and benchmarks. There is
no point in optimizing code that only uses 10% of the CPU time. 
At one point I spent a few years optimizing codes for vector
supercomputers. The speedups there can easily be on the order of
100x, but even in the case of specialized hardware, unless you
can find a section of code that is using 40%-50% of the cpu time,
optimization is often a waste of time. 

- This is just my rough guess, but I suspect that the most useful
optimization is on the back end. Busy ldap servers do a tremendous
amount of I/O, if you can find a way to optimize that you'll get a 
speedup worth your effort. I can't repeat this often enough: 

"Attempting to optimize code without first profiling it on real world
benchmarks is wanking off at best, and dangerous stupidity at worst."

- If you have time to work on openldap, the best use of it would be
to make sure it is working correctly. This is boring unglorious work,
but is by far the most beneficial to the open source community. On
most projects for every 100 programmers putting in new features,
there's at best one or two actually trying to make sure the existing
features work. 

- Booker C. Bense