AW: Storing Docroots in LDAP-DB / OpenLDAP Read Performance

["Jochen Tuchbreiter" <jochen@tuchbreiter.de>]

Hi,

thanks for your reply. I can?t resist to comment on some things O:-)


>I can see user ~ maps, but Docroot? Do you really change that information
>so often or on so many hosts that includes (managed with M4 or whatever),
>mod_perl scripted config files, and "apachectl graceful" won't do?

The point is that I would like to store all user information on one big
LDAP-DB which is authorative for all "webslaves" (posixaccount-information
for the users is also stored in this). Each webslave will keep a replica of
its part of the ldap-db, so that the main LDAP-server will not be SPOF and
will not get much load.

I have to be able to map domains/subdomains to directories absolutely
freely, a module like the mass vitual hosting mod ist not sufficent. Because
of this I need to use mod_rewrite. Since changes made to the
directory-mapping in the ldap-db have to take place immidiately I thought
about using an external rewriting-module that will get its information
directly from the LDAP-Server on the local host.

That?s why I asked about this - if there is a better way of doing this I am
more than willing to find out about it.

> Yes. But cache the results of the lookup in the Apache child processes or
> shared memory and you'll be OK.

Caching is a great idea but I guess I don?t have use shared mem since an
external rewriting engine as supported by mod_rewrite gets started once when
apache starts, gets its input from stdin and replys to stout (one big while
($line = <STDIN>) loop) and is not terminated till apache itself
terminates - I can probably simply store the caching info in a hash located
in the memory of the external rewriting-program.


LDAP-Performance:

I am quite suprised by this. I am currently doing some web-forwarding using
a simple fastcgi-script that will do one query to a mysql-database per
request and this performes absolutely killer - I can easily do >10
forwards/s on a PIII-500 without caching anything in the forwarding-script.

I can hardly imagine that sLDAP is any slower than a relational db, maybe it
is matter of tweaking configuration-files ? I have little experience with
slapd so far, I am only using it for a smtp/pop-toaster that runs qmail-ldap
and it performs ok over there after inserting some ldbm-caching lines into
the config.



Greetings,

Jochen