title: Measurement and Analysis of LDAP Performance link: https://onemoretech.wordpress.com/2007/11/14/measurement-and-analysis-of-ldap-performance/ author: lembobro description: post_id: 610 created: 2007/11/14 19:50:21 created_gmt: 2007/11/14 19:50:21 comment_status: open post_name: measurement-and-analysis-of-ldap-performance status: publish post_type: post

Measurement and Analysis of LDAP Performance

Measurement and Analysis of LDAP Performance by Xin Wang of Columbia University and Dilip Kandlur and Dinesh Verma of IBM, was a paper published in June 2000 for the SIGMETRICS 2000 conference.

To say that this paper was a key resource for me would be an understatement. It revolutionized the way I looked at LDAP design and operations.

There is a wealth of important information here. From practical experience in implementing most (but sadly, not all — hence my addition of this post to the “Corporate Politics” index of this site) of its recommendations I can say that they have been proved out in the real world, where many critical environmental factors (like network configuration of hardware) are outside the control of working LDAP admins.

The key points are these:

1. Disabling the Nagle Algorithm on both the directory server and in the application will make an enormous difference in reducing search latency (a seven fold reduction in response time).

2. Dual processor servers perform significantly better than single processor servers, whether Sparc or Intel based (a 40% improvement in performance).

3. Caching LDAP entries in the database to the limit of available memory will greatly improve performance (around 40% better in the study).

4. Entry size matters. Increasing entry size by a factor of 10 (e.g. 488 bytes to 4880 bytes) can result in a 30% degradation in performance.

5. Increasing directory size from 5,000 to 10,000 to over 50,000 entries, depending upon the limits of your cache, can result in degradations of performance of 60% or more

A telling statistic is that in an LDAP search over 40% of the time until entry return is taken by what are called “front-end operations”. These include building the search filter, ASN.1 encoding, sending the result, and sending the status. Of this operation time, 36.8% is taken up by ASN.1 encoding.

There are some other interesting observations. For example, the time to add an entry is roughly 4 times what it takes to search, while modify time, because it involves a search and “add”, usually will take as long as a search and add combined.

Although the study used OpenLDAP for testing, the observations made about the behavior of the LDAP protocol can be applied to any LDAP directory server. Specifics linked to the use of a BerkeleyDB back end would also be substantially the same for commercial directories derived from Netscape, which also use BerkeleyDB.

Copyright 2004-2019 Phil Lembo