A recent post on the Connexitor Blog was about performance and how modern software often lacks it. The post was mostly directed towards Sun and Redhat for stating that they provide a state of the art, fast directory server and how that’s not true compared to the performance numbers of these products against OpenLDAP. Later on it pointed out that modern development usually uses a lot of abstraction layers and ends up creating bloated and heavy products which cannot achieve decent performance.

I must agree on the optimization comments. We try to do the same in FreeRADIUS, adding features as well as optimizing things whenever possible in order to create a flexible yet blazing fast server.

I will take the role of the devil’s advocate on the directory server front though.

Most organizations, companies and universities have a typical user population of much less or at least not exceeding 250,000 entries. The less entries you have, the less interested you are on sheer performance numbers of your directory server. Usually, administrators will take many more factors into consideration than just the number of auths/sec. And, according to Symas own benchmarks FDS can perform 4,500 auths/sec and 48,000 entries/sec for a 250,000 entries database. Numbers that are usually more than enough for the kind of load expected from a user population of that scale.

What administrators will also look out for when choosing a directory server (apart from performance number) are:

  1. Dynamic configuration through an ldap interface
  2. ACIs on the DIT
  3. Configuration console for easy server administration
  4. Monitoring capabilities
  5. An included ldap proxy server
  6. Active Directory Sync included with the directory
  7. Extensive documentation, preferably in the form of various guides (Administrator’s, Deployment, Tuning, Installation, and so on)
  8. Ease of installation
  9. Available plugins, backends, overlays. Features like class of service, roles, referential integrity, attribute uniqueness, password policy.
  10. Commercial support and training

If someone were to check the above list with both FDS and OpenLDAP he might find out that overall FDS might be better equipped to handle the above requirements. Specifically:

  1. Draw, although i think that OpenLDAP allows for an even broader range of changes while the server is running
  2. Draw
  3. FDS has a Java Console, i am not aware of a console offering for OpenLDAP.
  4. Both servers provide a monitoring backend. FDS also provides cache hit statistics something that i am not sure OpenLDAP provides.
  5. A big plus for OpenLDAP. You might end up installing OpenLDAP along side FDS only to provide an ldap proxy functionality (if you are in need of one).
  6. FDS provides one. I am not aware of something similar for OpenLDAP
  7. FDS provides a far richer suite of documentation all readily available on it’s website. OpenLDAP documentation is lacking, especially on areas such as fine tuning the server (there are multiple cache memory settings and other configuration directives which are available for tuning) or setting up replication (with examples and use cases). It’s not uncommon to have to look through mailing lists archives in order to find more information on various aspects of OpenLDAP advanced configuration.
  8. FDS provides a setup utility which allows for easy first time configuration and multiple silent installs. I haven’t seen what CDS has to offer in this area so i cannot comment on this subject.
  9. Both products are quite feature full. OpenLDAP provides more exotic plugins,overlays and backends. FDS provides the Class of Service and Roles mechanisms which can prove very useful at times (i haven’t found something similar with OpenLDAP).
  10. Draw if you are willing to use the commercial versions of the products (Redhat DS or CDS).

Overall, i wish there was an rpm for OpenLDAP which included the setup utility of FDS, multiple documentation guides and a strong console interface allowing the administrator to tune almost every aspect of the server, especially things like performance and replication. Or that FDS included an LDAP Proxy, more plugins and performed as well as OpenLDAP :

I don’t intend the above as a flame to OpenLDAP. I actually like the software, how rich it is in available features and we use it in my university as an LDAP Proxy. I am just trying to point out the fact than when you want to call your product the best you have to see beyond performance and take a look at other important issues. I really do hope that both products will improve on the areas they are lacking and we ‘ll end up with a couple of really strong packages.

Update: Symas (Howard Chu) sent me some comments on the above checklist as well as some more thoughts. I ‘ll agree with everything, just have to point out once more than the above refer to installations holding less (or far less) than 250,000 entries.

Nicely thought out commentary. I think some things need to be clarified

In the benchmark, that “48,000 per second” number is the rate of entries
being returned in a single ldapsearch. That’s not the number of
ldapsearches per second, that number would be closer to 2x the authrate,
and would depend on the search filter complexity, size of the result
set, etc. I measured this rate to get a handle on the efficiency of the
database backend by itself. I.e., the authrate really reflects the
backend efficiency in concert with the server frontend.

For your checklist:

3 – I’ve never seen the need for a dedicated server console, since any
LDAP client will do and there are many to choose from. I personally use
JXplorer. That said, some Project members have recently begun work on an
OpenLDAP console, for folks who like all the pieces of their tool suite
to carry the same brand name…

4 – The amount of info available has been extended in 2.4, including
much more cache stats.

5 – We have a few customers who are too paralyzed to migrate from their
existing servers, but use the OpenLDAP proxy as a frontend because our
BER library is better. I.e., their servers are still vulnerable to a lot
of well known malicious packet attacks.

6 – not in open source, strangely enough. We’re working on getting it
contributed back.

7 – We finally have someone stepping up to spearhead the Admin Guide
rewrite. I’ve made this a top priority for the Project this year. Also
my book on OpenLDAP Administration will be available in a web preview
edition soon.

8 – CDS installs quickly and painlessly. None of our customers has
needed any assistance with installation.

9 – even the designers of the role mechanism admit it was a mistake.
Roles are groups, nuff said.

0 – Of course CDS only costs $6k for a license, vs RHDS $15k.

To your point about university environments… Stanford University was
running Netscape DS4, but they needed 9 Ultrasparc servers to handle
their load. Back in 2001 their directory was only around 250,000 users
but aside from the individual servers being too slow for the traffic,
they also spontaneously corrupted their DBs all the time. Stanford
contacted Symas to help them get OpenLDAP 2.1 with back-bdb deployed and
their DB corruption issues disappeared. When we were done they could
handle all of their campus traffic using a single server. (See their
story here
http://services.stanford.edu/directory/openldap/history/index.html )

So maybe you don’t think absolute performance is so critical, but
anything that can offer you a potential 9:1 reduction in hardware cost
is worth it, no matter what size of “enterprise” you’re running. Not to
mention the 100% reliability that comes along with it.

Anyway you’re right, it’s not just about performance; that’s only one
aspect of superior technology. Having better technology also makes
things easier to deploy, easier to keep running, easier to extend,
easier to afford, etc….