BOSTON (05/15/2000) - You 've really got to know what you want to do with your Lightweight Directory Access Protocol (LDAP) server before you decide to buy one.
In the past five years, LDAP has been elevated to the de facto standard for how users and applications access information stored in a directory server. There are a variety of LDAP server products on the market today that attempt to get one job done: answer directory queries over LDAP. But these products all arrive at that end in different ways and with varying degrees of success.
We looked at a broad spectrum of LDAP directory servers, including simple but fast servers for use inside large Internet sites, enterprise directory servers with integrated LDAP support, X.500 servers with LDAP front ends and relational databases with LDAP built on top.
We invited more than 30 LDAP vendors to participate in our test, which centered around focused management simplicity, standards compliance and performance.
Overall, we looked at how well these directory servers could handle LDAP clients - users and LDAP-enabled applications - accessing the data.
We also looked at the accessory tool sets offered with each product. A tool set typically comprises data formatting tools that format your data before you bulk-load it and directory query tools that let you see inside the directory. A tool set may include other bits and pieces, such as a schema editor, that help make the manager 's job easier but are not part of the LDAP server itself.
To level the playing field, we asked all vendors to send Windows NT versions of their products. Seven products arrived in our test labs. IPlanet's Directory Server and Innosoft International Inc.'s IDDS were the pure LDAP servers we tested. Novell Inc.'s NDS eDirectory for NT was the general-purpose directory server we evaluated. The X.500-based servers we looked at were Critical Path Software Inc.'s Global Directory Server, Computer Associates International Inc.' eTrust Directory and Siemens AG's DirX. Oracle Corp.'s Oracle Internet Directory (OID) was the lone server we tested that grew out of database technology. We could not complete benchmark testing for the Oracle product due to time constraints involved with this review. We are currently testing Oracle 's product and will publish these results in print and on the Web when they become available.
We also evaluated Microsoft Corp.'s Active Directory running on Windows 2000 and an open source alternative, OpenLDAP, running on Red Hat Inc.'s Linux. We did not include those products in our head-to-head evaluation because of the variables introduced by the different operating systems.
The goal of our benchmark tests was to assess how these products handled LDAP functions only. Our LDAP query mix included messaging, addressing and modifying.
The messaging queries simulated the stress an e-mail gateway or e-commerce application would put on a directory, with exact-match queries looking up entries in the directory.
The addressing queries simulated an application, such as a white pages or yellow pages directory, with queries on different fields, including some wildcard queries.
The modifying tests simulated online directory update operations, as opposed to bulk-load operations.
Our second goal was to assess the tools each of these vendors offered for managing and monitoring these LDAP services, and the back-end services they provide with their products.
Our first goal could be accomplished via an objective benchmark, but the second would require a subjective assessment by this reviewer. We opted to present both evaluations separately.
We awarded our Network World Blue Ribbon award to iPlanet 's Directory Server because it won the performance ratings and offered quality management utilities.
The short answer on performance is that if you care about how fast your LDAP directory is, you should use iPlanet 's Directory Server. In eight test scenarios, Directory Server was the fastest directory in six of the tests and second in the other two. Innosoft 's IDDS beat Directory Server in the two instances where Directory Server placed second.
What we called messaging performance would be key in an e-mail or e-commerce application because it applies direct hits on indexed fields to return records from the directory. Companies with their roots in messaging, including iPlanet, Innosoft and Critical Path, all did very well here.
Novell also did a good job, probably because the performance profile of an operating system directory matches that test very well - a lot of queries and few wildcards.
Our messaging performance numbers, however, were slightly skewed because we chose a small enough directory that a good directory server could cache the entire directory in memory. Directories with up to about one million entries are easily and inexpensively stored in main memory. If you plan to go much above that, you probably won 't see performance numbers nearly as good as we got.
The addressing performance test uncovered a different set of winners. Although iPlanet 's Directory Server still came out on top, the spread between the other products was not as large. Because of the variability in inexact matches, a careful evaluation of your query type and the performance of your directory would be vital to ensure that the directory will be fast enough for the application.
Directories that have a higher proportion of modify operations will also require that you engineer things carefully. While Directory Server, Innosoft 's IDDS and Critical Path 's Global Directory Server all turned in numbers near 100 modifies per second, the other directories we tested couldn 't handle nearly that amount.
In response, Novell officials say their directory is not optimized for bulk loading on NT.
Bulk-loading performance could be a killer issue for many directories. If your LDAP directory is being built as a combination of other back-end databases or from a data warehouse, you might want to drop and reload the directory every day and that would require a bulk load each time. Innosoft 's IDDS and iPlanet 's Directory Server do this task really well.
Novell 's NDS eDirectory and the X.500 directories that made us load over protocol - instead of using a special tool - do a poor job.
Novell 's NDS eDirectory had a bulk-load time of eight-tenths records per second, taking a mind-numbing 35 hours to load our test data set, compared to the winning time of less than four minutes registered by Innosoft 's IDDS.
IDDS and Directory Server are even better than they look in our charts because you can be bulk-loading one directory while the LDAP server is still loading and then switch directories almost instantly.
If all you want is LDAP, iPlanet 's Directory Server is the clear leader in that category, although there were some very close contests between Directory Server and IDDS.
A more interesting question is can you use a general-purpose directory service such as Novell 's NDS eDirectory as an application 's LDAP server or are they really only appropriate for operating system directory functions? Novell 's case is tenuous, at least on the NT platform. A directory that crashes under load simply can 't be recommended. During light load testing - for example, one client hitting it really hard - NDS eDirectory ran fine. But when we increased the load to 10 clients hitting the directory, it crashed. Presumably, because NDS has been available for years on NetWare, it behaves much better on its home territory. However, because we were looking for one platform upon which to compare various LDAP products, we chose NT, and Novell readily submitted its NT-based product for review.
With the X.500 directories, it 's a mixed bag. Performance is mediocre with the exception of Critical Path 's Global Directory Server, but even then you would have to take into consideration what LDAP applications you want to run against this directory. In general, going to an X.500 plus LDAP server is only advisable if you need the X.500 back-end features of the directory. In that case, your X.500 requirements and LDAP integration needs would govern which directory is best for you.