state-threads
[Top] [All Lists]

Re: Using with LDAP

To: state-threads@xxxxxxxxxxx
Subject: Re: Using with LDAP
From: Dan Melomedman <dmelomed@xxxxxxxx>
Date: Mon, 16 Jul 2001 18:14:17 -0400
In-reply-to: <3B535EDE.C9E3B861@xxxxxxxxxx>
Mail-followup-to: state-threads@xxxxxxxxxxx
References: <000701c10de0$24b372a0$dbbfa8c0@xxxxxxxxxxxxxxxxxxx> <20010716145831.D231@xxxxxxxx> <3B535EDE.C9E3B861@xxxxxxxxxx>
Sender: owner-state-threads@xxxxxxxxxxx
User-agent: Mutt/1.3.18i
On Mon, Jul 16, 2001 at 02:38:38PM -0700, Gene Shekhtman wrote the following:
> 1.  Use very simple LDAP "helper" server that listens to a local (UNIX domain)
>     socket and accept()s connections from the "main" server which calls ST
>     functions (st_connect(), st_write(), st_read()).  The "helper" server may
>     just pre-fork a fixed (and always constant) number of processes that use
>     Netscape directory SDK.  Of course, you'll be able to have only as many
>     simultaneous LDAP queries as the number of processes in the "helper" 
> server.

This should work very well for usual server loads where most people have
authenticated themselves and most data is sitting in cache. But if the
LDAP server replica is running on the local machine to avoid network I/O,
this cache could be rendered useless since LDAP servers maintain their own
cache. Also, even if the LDAP server is not local to the state-threaded
server, what happens when hundreds or even thousands of LDAP queries are
needed when they're not in cache? Preforking too many processes would
IMHO create too much kernel overhead, while having those processes in
deficit would create delays. Is there a better way?

Also, what would be an efficient model for disk I/O helpers?

<Prev in Thread] Current Thread [Next in Thread>