RE: Unidentified subject! LDAP search times and databases

["Kim Fenley" <kfenley@ozemail.com.au>]

Martin

More on Tim Hahn comments.


There are many factors that will influence the search times on LDAP
Directories.

The Database its self - here many are built on a proprietary DB and so not
as well developed as are the industrial strength Dabs.

Then there is the issue of indexing of Attributes.  The more Attributes
indexed the faster the search, but there are drawback in other areas and are
dependent on how the Directory is structured.  A lot can't index all
Attributes as it has a server performance impact.

Next is the fact that many directories requests to the backend DB are via
SQL, which requires row and column search.  This is probably the most
limiting factor.  The larger the number of entries the slower the search.

When you combine all these different factors together you end up with poor
search times.  Many vendors now run schema in memory to increase search
performance and large hardware platforms to make up for the poor performance
of the Directory engine.  This leads to other issues of data integrity and
robustness if power is lost, caching of schema in and out of memory - some
systems seem to stop with this happens.

I know one only one LDAP Directory that overcomes all these issues and runs
on an industrial strength backend DB which provides predictable sub-second
searches, full rollback, auditing and logging and has 30+ patents on the use
of a RDBMS for Directories.  This is why the other vendors who use RDMBS
technology are unable to compete, as they have to use standard SQL calls.
The Patents cover how you use a standard RDBMS as an OO D/B without the SQL
row and Column problem and this is where the high search times from a RDBMS
come from.  It also does both Distribution and Replication, load sharing and
support millions of concurrent user accesses over 100's of millions of
entries.

The Computer Associates - eTrust Directory (formally (OpenDirectory).  Its
the only truly Distributed operational Directory and is an infrastructure
Directory, not a Desktop solution or network or address book derived
Directory.  Its been replacing LDAP Server technology in Banks and Carriers
sectors where performance, failover, scalability, reliability, robustness,
fully indexed Attributes and 1000s of searches per second of a  predictable
nature.  Have a look at:

www.opendirectory.com.au

Kim





-----Original Message-----
From: hahnt@us.ibm.com [mailto:hahnt@us.ibm.com]
Sent: Wednesday, 7 June 2000 7:21 PM
To: ietf-ldapext@netscape.com
Subject: Unidentified subject!


Greetings,

In general, due to the wide variety of database engine implementations on
which different LDAP
directories are based, it is safe to say that 'your mileage may vary'.  As
everyone has indicated,
update performance is related to all the extra things a directory server
might do as a result
of the modify operation.  What these things are is dependent upon the
underlying database
implementation upon which the directory is based.

Thus, some existing implementations may offer fast update performance while
others may not.

> Hi,
>
> I am working on a problem where LDAP would be used to keep a directory
with
> user data.  One concern I have is that LDAP is supposed to be less
efficient
> when it comes to intense write operations.
>
> Can LDAP handle millions of users data in a directory where some of the
data
> (a few attributes) needs to be updated very frequently?  How would that
> affect performance and is LDAP effective when the searched data must be
> returned prompty with very little delay?
>
> If anyone has any comments on this, I would appreciate it,
>
> Martin Rahm

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681