Preparing your LDAP Directory for HP-UX Integration

Performance Considerations

One design goal of a directory is that it is optimized for excellent read and search performance. However,

this means that a directory server must be tuned to achieve the best performance for the application for

which it is intended. Using an LDAP directory as a repository for Posix data means you will need to tune

your directory for this purpose.

Increasing Search performance

The methods used to tune a directory depend on the architecture of the database used by the directory.

Because read and search performance is important for a directory, an "indexed" database architecture is the

preferred choice of most directory vendors. If your database architecture is different, refer to your

documentation to tune your directory for the requirements described below.

In order to increase search performance on an indexed directory, the database needs to know what criteria to

use when searching for information in the database. As an example, if you often look up people in the

directory by their last name, your directory should be "indexed" by the surname (sn) attribute. An index is a

sorted table (usually a balanced b-tree) of the search key (surname in this example.) Once the key is found

in the index, pointers point to the actual data.

The naming services on a Posix system need to look up information based on several attributes. As an

example, the ls command needs to look up user information based on the user's Posix uid number. The

logic behind the ls command can be expressed in a colloquial way... "Hmm, I just found a file called

'January_Report' and it was created by user number 8532. I need to print out this user's name, so I need to

search for this user using that number as a search key." So, the ls command calls the Unix naming

procedure getpwuid(), to retrieve the entry with the matching uid number, and then map the user's uid

number to the user's uid name.

What this means to the directory is that the database should be optimized when searching for a uidNumber.

And, there are many other examples for other attributes. So, to summarize, the tables below identify the

attributes that should be "indexed." You (the Directory Administrator) will only need to create indices for

databases that are used by the HP-UX system. If, for example, you use the local file copy of the

/etc/services file instead of using LDAP, then you don't need to index the ipServicePort attribute.

Note: To determine which databases you access via LDAP, examine the /etc/nsswitch.conf file on all

your HP-UX systems. Clients of the NIS/LDAP Gateway will specify "nis" in the

nsswitch.conf file. NIS requests will eventually end up as LDAP requests. The LDAP-UX

Client Services project uses "ldap" as the key in the nsswitch.conf file.

You probably do not need to index the attributes for small lists. For example, the /etc/protocol file is not

typically very big. So typically you would not need to index the ipProtocolNumber attribute. A general rule

of thumb would be: Databases that contain more than 100 entries should be indexed by their key attributes

(shown below.) The following table describes the attributes you may wish to index, and the Posix APIs

which require those indices.