state-threads
[Top] [All Lists]

Re: Using with LDAP

To: state-threads@xxxxxxxxxxx
Subject: Re: Using with LDAP
From: Gene Shekhtman <gsh@xxxxxxxxxx>
Date: Mon, 16 Jul 2001 17:16:27 -0700
Organization: Abeona Networks, Inc.
References: <000701c10de0$24b372a0$dbbfa8c0@xxxxxxxxxxxxxxxxxxx> <20010716145831.D231@xxxxxxxx> <3B535EDE.C9E3B861@xxxxxxxxxx> <20010716181417.A352@xxxxxxxx>
Sender: owner-state-threads@xxxxxxxxxxx
Dan Melomedman wrote:

> 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.

Local "in-process" cache is never useless :)  It's just a different level
of caching (just like bigger L2 CPU cache doesn't make L1 cache useless).

> 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.

I had in mind about 10 processes or so.  If a LDAP query takes 20 ms,
you'll be able to handle 500 queries per second.

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

The Flash web server used disk I/O helpers for disk-bound workloads
<http://www.cs.rice.edu/~vivek/flash99/>.  I think the source code is
available free of charge for non-commerial use.




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