Subject: Unidentified subject!

From: [email-masked]
Date: Wed, 7 Jun 2000 05:21:20 -0400

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: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

---

From: "Kim Fenley" <[email-masked]>
Date: Thu, 8 Jun 2000 09:37:27 +1000

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, 7 June 2000 7:21 PM
To: [email-masked]
Subject: Unidentified subject!

Greetings,

with
efficient
data

Regards,
Tim Hahn

---

From: Colin Robbins <[email-masked]>
Date: Fri, 9 Jun 2000 09:25:35 +0100

> of a RDBMS for Directories.

Sorry folks, I really don't like using this lists for vendor messages, but
OpenDirectory is not the only product in the world with an industrial
strength backed DB overcoming these problems.   There are several.

> This is why the other vendors
> who use RDMBS
> come from.

If I understand this correctly, you are saying you have several patents to
implement an OODB on top of a RDBMS.  The implication is you need an OODB to
implement an efficient LDAP Directory.

I certainly agree with the implication.  This is why at NEXOR we decided to
implement our Directory product using an industrial strength OODB from
Versant Technologies (http://www.versant.com).  This approach has all the
benefits you refer to, with the added advantage on not having the overhead
of mapping onto a RDBMS.

As to the original question posted - this approach of using an OODB, enables
us to manage "intense write" scenarios, with very little impact upon search
performance.   You only get a blockage if the attribute being modified, is
the target of a concurrent search and pointed to be the search index - the
DSA needs to wait for a read lock to check the attribute.  In our experience
this occurrence is rare.

Once again, sorry for using this list for a vendor message, but I fell
compelled to respond when I see messages suggesting there is only one good
product in the world.

Colin Robbins
NEXOR

Tel:  +44 115 952 0583
Email:  [email-masked]
WWW:  http://www.nexor.com

---

From: "Alexis Bor" <[email-masked]>
Date: Fri, 9 Jun 2000 07:44:08 -0400

Out of curiosity, have you tried this with a server that has, let's say
10,000,000 entries in it and trying to add entries with 100 or so
attributes?  How fast can you do that?  Cache management starts to get in
your way, since you won't have enough memory on your system, not to mention
specific operating system overhead that kicks in.

I did a couple of years ago and it left me wondering...And I hope that
people have looked into this since then...

-- Alexis

Alexis Bor
Directory Works, Inc.
[email-masked]
http://www.directoryworks.com

-----Original Message-----
From: Colin Robbins [mailto:[email-masked]]
Sent: Friday, June 09, 2000 4:26 AM
To: 'kfenley'; 'hahnt'; 'ietf-ldapext'
Subject: RE: Unidentified subject! LDAP search times and databases

Colin Robbins
NEXOR

Tel:  +44 115 952 0583

---

From: Colin Robbins <[email-masked]>
Date: Fri, 9 Jun 2000 13:16:02 +0100

No, we have not tried that specific test, but it would be fun to try.
If you want to try it out in your test rig, I am sure we can get you the
software...

If such a test were performed, I have every confidence that the object
caching model of the Versant OODB would provide excellent results.

Colin

> From: Alexis Bor [mailto:[email-masked]]
> Sent: 09 June 2000 12:44
> To: Colin.Robbins; 'kfenley'; 'hahnt'; 'ietf-ldapext'

---

From: "Alexis Bor" <[email-masked]>
Date: Fri, 9 Jun 2000 08:55:42 -0400

Colin,
I don't have access to that test system at the moment, but next time I do,
I'll keep it in mind.  I suspect that it will work well, based on what I
know about Versant and some other factors, but it would be fun to see...

-- Alexis

Alexis Bor
Directory Works, Inc.

-----Original Message-----
From: Colin Robbins [mailto:[email-masked]]
Sent: Friday, June 09, 2000 8:16 AM
To: 'Alexis Bor'; 'kfenley'; 'hahnt'; 'ietf-ldapext'
Subject: RE: Unidentified subject! LDAP search times and databases

Colin