LDAP-UX Integration Performance and Tuning Guidelines

Client Profile
Determining the average and peak number of requests by an LDAP-UX client is very complicated. This section is
primarily focused on resolving that question. The average and peak load of a client can vary dramatically. There
are several factors that help determine client load on the server (roughly in most significant order.)
• Types of applications used on the client.
• Configuration of the client’s /etc/nsswitch.conf file.
• Level of activity on the client.
• CPU performance of the client.
• Effectiveness of pwgrd.
• Effectiveness of ldapclientd cache daemon
Types of Client Applications
Of all the factors that affect client load on the server, the type of application used on the client is probably the most
significant. A single application on a single client is capable of generating enough requests to demand nearly all the
performance capacity of the LDAP server. As an example, a single program that sits in a tight loop calling
getpwnam(), can generate over 240 requests per second to the LDAP server, requiring 85% of the available CPU on
a one-way A500 server (see table on page 13 for details.) Two similar programs (or the same program with multiple
threads) on the same client can generate enough requests to nearly use %100 of the LDAP server’s CPU. Note: This
statement is somewhat of an exaggeration, as typically two caching daemons, one provided by LDAP-UX called
ldapclientd and another on HP-UX, called “pwgrd” (see page 9 for more information) often prevents unnecessary
and repeated queries.
Programs of that example are not typical. However, there are some example programs that do generate significant
load:
• “ls –l”
Generates a getpwuid() and getgrgid() for every file displayed for every unique owner or group displayed.
• tar
For every file archived / extracted, tar calls getpwuid() and getpwnam() / getgruid() and getgrnam().
• who
For every user logged into the system, who calls getpwuid().
• finger
finger calls getpwent() repeatedly until it finds the user it’s looking for. finger was designed using the
older architecture. Applications that need to discover user account information should do so through the
getpwnam() or getpwuid() APIs, instead of enumerating all accounts. In general, any program that attempts to
enumerate (calls any of the getxxent() routines) will cause significant load on the directory server. Since LDAP
directories can store millions of users, any program that attempts to enumerate all entries, will surely not scale
in that type of environment. If possible, eliminate these programs from your environment. See “Preparing
Your LDAP Directory for HP-UX Integration”
3
for more details on the pitfalls of enumeration.
There are many other types of applications that generate extensive requests, such as an SMTP mail server gateway
(that validates email addresses) or various types of network programs (such as when a web server authenticates a
user.) For this reason, determining client load may be impossible without actual measurement. See page 12 on how
to collect load data.
Page 6