Preparing your LDAP Directory for HP-UX Integration

24
Bulk Search Reply
When responding to a search request, some LDAP servers choose to compile the entire reply before
transmitting the results to the client. This architecture can cause several problems when enumerating large
data sets:
• Latency caused by building up the response will slow down applications that enumerate. Depending
on how long it takes for the server to generate the response may cause clients of the NIS/LDAP
Gateway to time out.
• The size of the data may grow beyond the capacity of the server to complete the request.. This may
cause the LDAP server to abort with an out of memory condition.
If you have applications that do need to enumerate a large Posix data set, you should discover how well your
directory server will perform when attempting to enumerate the entire data set. Use the following
ldapsearch command to help you analyze your server's performance. In this example, we assume that you
have a large number of Posix accounts.
ldapsearch -b baseDN -T "(objectclass=posixaccount)" dn uid uidnumber | tee /tmp/allaccounts
• Did your server reply immediately or was there a delay before the first entries started to appear?
If there was a delay, then you may have a bulk reply problem or an indexing problem (see
"Enumeration of non-indexed data" next for indexing tips.)
• Were all the Posix accounts displayed? Use "wc -l /tmp/allaccounts" to count the number of
entries. Divide that number by 4. It should be equal to the number of Posix accounts you
expected to see.
• Did your LDAP server abort? It may have run out of memory. With a Netscape 4.x server, this
problem can likely be solved with proper indexing (see the next topic.)
If your LDAP directory server failed the above test, you may need to contact your directory vendor do
discover why. If properly configured a Netscape 4.x server should return search results as they are found.
It does not generate a bulk reply.
Enumeration of non-indexed data
If your LDAP server is not properly indexed, enumeration search requests may be unacceptably slow, or
even may cause your LDAP server to abort. As described above, when an application needs to enumerate
all accounts or groups, it needs to send a large search request to the LDAP server. For example, the
NIS/LDAP Gateway could send a search request that says "give me all the entries found under the
ou=People,o=hp.com subtree and where the objectclass is of type posixAccount ." The only database
index that could be used to satisfy the search request would be the index for the objectclass attribute. So
when the directory server consults the objectclass index, it would find the matching pointers for the
posixAccounts. However, if your database contains a very large number of posixAccounts, the pointers for
the posixAccount may not exist.
FYI: Indexes are expensive to maintain. Indexes require a lot of disk space and physical memory.
And modifications to directory entries also must update the appropriate indexes which can be
costly if there are many and/or large indexes. Thus, creating indexes with abandon can actually