LDAP-UX Integration Performance and Tuning Guidelines

Gathering Data
Given the many complications on determining average client load, perhaps the only way to discover the load
generated by a client is to measure it directly in a small deployment.
One methodology is to deploy LDAP as a name server is to first select a small subset of typical systems that could
be used to represent an average environment. The following steps could be used to measure client load:
1. Select a small subset of “typical” clients to be used to calculate an average load.
2. Determine which services (passwd, group, aliases, etc…) are best served by LDAP, while others remain served
by files or other repositories.
3. Load the directory server with the selected name service data.
4. Configure the /etc/nsswitch.conf file on those clients to use “ldap” for the selected name services.
5. Determine how long you wish track client data. At least 24 hour period is suggested. Attempt to track periods
which are likely to have heavy load (during backups, logins, etc…)
6. Using the “dirload” tool from Appendix A, monitor the directory server load:
cd /var/opt/netscape/servers/slapd-serverName
/tmp/dirload 24 > /tmp/server_load
a. Examine the /tmp/server_load file. This output file from dirload tool will contain the total number of
requests, average requests per second as well as an estimate as to the peak number of requests per second.
Divide those numbers by the number of clients to determine the average and peak load of a single client.
b. Calculate the maximum number of clients per server using the following formula:
DirMarkSearchPerf
MaxClients =
PeakRequests/sec * SafetyMargin * PerformanceFactor * (1-CacheRate)
DirMarkSearchPerf: Values for various servers’ performance results from DirectoryMark
5
search tests, as
well as specifications on how those results were obtained, can be found in Appendix B on page 17.
DirectoryMark was selected as a benchmark for measuring performance of LDAP-UX since it is widely
available.
PerformanceFactor is a value that compensates for the performance assumptions defined on page 5, as well
as accounting for the performance characteristics of architecture of the LDAP-UX product. This value is a
constant of 3.5. Some of these characteristics are:
 The type of search filters used by LDAP-UX.
 The “typical” ACIs used in the directory server.
 The “typical” number of entries in a directory server (150,000)
 The time required to execute the LDAP-UX client code (“code path”.)
 The number of LDAP operations generated by LDAP-UX per request.
SafetyMargin
accounts for variables those are difficult to calculate, such as unexpected events, etc….
Recommended value is between 2 and 5.
CacheRate
covers the effectiveness of ldapclientd and pwgrd,. CacheRate for ldapclientd is reporterd by
ldapclientd –s and by pwgr_stat for pwgrgd. To determine the CacheRate, run ldapclientd –s and
pwgr_stat on several “typical” clients. Calculate a weighted average for all services (passwd and group)
on all clients. The averages must be weighted by the number of requests. The Cache rate for ldapclientd
cache daemon can be calculated by (cache_hits_pos + cache_hits_neg) / cache_reqs.
For an example, refer to Appendix C for sample data from a
dirload test run in the HP’s lab development
environment.
5
DirectoryMark, Mindcraft Inc. DirectoryMark is a LDAP directory server performance testing tool, available at
http://www.mindcraft.com/directorymark/
Page 12