tinyldap - a small LDAP implementation

What is it?

tinyldap is an attempt to write a very small and very fast LDAP server. openldap is the reference when it comes to LDAP servers, and it performs very poorly despite using techniques such as thread pools.

The latest version is always available via anonymous CVS (which is the recommended way to get the sources):

  $ cvs -d cvs -d :pserver:cvs@cvs.fefe.de:/cvs login
  (Logging in to cvs@cvs.fefe.de)
  CVS password: [just hit return]
  $ cvs -d cvs -d :pserver:cvs@cvs.fefe.de:/cvs -z9 co tinyldap

If you want to take part in tinyldap development, please subscribe to the tinyldap mailing list (send an empty email to tinyldap-subscribe@fefe.de).

Recent News

[20060301] I'm still working on tinyldap. tinyldap has ACL support now, a new index type (twice as large and twice as fast), the client can parse RFC-style search expressions. The only thing missing for a release is write support. I'm working on it.

[20020821] an LDAP based checkpassword for qmail-pop3, also works as courier auth module.

[20020403] first tarball uploaded.


I installed openldap and set up a slapd. I put in some 3000 records. I asked for a specific record. It took 0.75 seconds on an otherwise idle 1.3 GHz machine. That is absolutely unacceptable, even if slapd does a sequential search. To prove that I wrote a small LDIF parser that parses the same data in 0.02 seconds on the same hardware. Also, openldap is far too heavyweight for my taste.

Adding an index to openldap made it much faster (7 seconds for 1000 queries), but a trivial tinyldap query implementation that does a sequential search has about the same speed as that. I also wrote an index module for tinyldap and it can now to 1000 queries in less than 1 second on the same hardware, although one new process is forked and executed for each request.


About the database backend

I spent some time defining a trivial file format for a generic text database with records and attributes where a record can have multiple attributes of the same name. The database format does not use compression but is nonetheless smaller than the LDIF source file, even with two indices (at least for my test data, about 3000 records). The file format should be generic enough to be useful for other purposes, too. One could, for example, write a simple SQL layer on top of it.