LDAP-UX Integration Performance and Tuning Guidelines February 19, 2004 Third Edition U.S.A.
Audience ........................................................................................................................................................ 1 Introduction .................................................................................................................................................... 1 Quick Summary.............................................................................................................................................. 1 Document Flow.............
LDAP-UX Integration Performance and Tuning Guidelines Audience This document is intended for HP-UX system administrators as well as enterprise directory architects. Readers of this document are expected to have a good understanding of Unix style operating systems, fundamental networking knowledge as well as a good understanding of LDAP directory server administration.
Note: Raw data and a client load tool from the HP performance test lab are available at the end of this document to support the sample data presented in this table. In order to achieve peak performance it’s critical that the directory server be configured properly. Please also review “Preparing your LDAP Directory for HP-UX Integration,” 3 mentioned above, for directory performance tuning guidelines. Since first publishing this document, the LDAP-UX product now include the ldapclientd cache daemon.
LDAP-UX Integration Performance and Tuning Guidelines The NIS/LDAP Gateway can act as an NIS server for many NIS clients (maintaining one connection to the LDAP server, on behalf of many clients.) The NIS/LDAP Gateway also has tunable caching. The NIS/LDAP Gateway acts as a buffer between the client and LDAP server. This reduces the load on the LDAP server significantly, as compared to many clients accessing the LDAP server directly.
The Name Service Switch The name service sub-system consists primarily of three components: the API, the switch (see man 4 switch,) and the back-end libraries. This architecture allows any type of repository to serve the APIs, such as files (/etc/passwd for example,) NIS or LDAP. This switch is controlled by the /etc/nsswitch.conf file, and allows any name service API to be served by any backend repository that supports that API.
LDAP-UX Integration Performance and Tuning Guidelines Performance Factors The number of client search requests generated is the most important factor in determining the number of clients an LDAP server can support. Additional factors are • The effectiveness of the pwgrd caching daemon. • The effectiveness of the ldapclientd cache daemon. • The types of search requests (enumeration vs.
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.
LDAP-UX Integration Performance and Tuning Guidelines Name Service Configuration Aside from the common example above of programs that call the getpwxxx() procedures, there are obviously other programs that call various other name service APIs, such as getservbynam(). The /etc/nsswitch.conf (man 4 switch) defines which subsystems will serve those API calls. The load on the LDAP directory server will increase for every service defined to use “ldap” in the /etc/nsswitch.conf file.
Client Activity User driven activity on the client can lead to increased load on the LDAP directory server. This level of activity can often cause peak loads during certain periods of the day. Examples of this could be a rigorous work schedule, which calls for all employees to login by 8:00AM. Or it could be caused indirectly, such as a regularly scheduled system backup on many simultaneous systems.
LDAP-UX Integration Performance and Tuning Guidelines will help and administrator to set the cache_size parameter. Following is the sample output of /opt/ldapux/bin/ldapclientd –s . Administrator can set cache size according to first two entries from the statistics. mem_in_use and high_mark_mem gives good idea of how much memory is being used right at that moment and highest level at the memory has reached so far. $ /opt/ldapux/bin/ldapclientd -s mem_in_use ............ 40281 high_mark_mem .........
Enabling SSL has minimal impact on the performance of the LDAP-UX client because of the how LDAP-UX maintains a semi-persistent connection to the directory server. This constant connection to the LDAP directory server minimizes the expensive overhead of SSL connection establishment. pwgrd pwgrd is an HP-UX system-wide caching daemon. It supports the passwd and group name service subsystems. This daemon is enabled by default on HP-UX, and can greatly reduce the load on the LDAP directory server.
LDAP-UX Integration Performance and Tuning Guidelines It can be difficult to determine how well pwgrd will reduce the demands of the LDAP-UX client on the LDAP server. One of the best ways is to measure an actual client. Performance vs. NIS NIS is a dedicated name service subsystem, designed only to serve Posix-style naming information. LDAP’s design allows it to be a highly adaptable tool, and has many uses.
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.
LDAP-UX Integration Performance and Tuning Guidelines Test Environment The following systems and configuration were used in the performance test environment: a-class Configuration: l-class Specification: Model: A400 / A500 CPU: 1-Way @ 440mhz / 2-Way @ 440mhz Memory: 1152MB / 2048MB OS: HP-UX B.11.00 64 Bit Patch Set: General Release Patches, September 2000 Software: LDAP-UX Integration B.03.01 Model: L2000-44 CPU: 2-Way 440mhz Memory: 1024MB OS: HP-UX B.11.
Test Data To determine the maximum performance (requests per second) that the LDAP directory server could handle, two A-Class clients were used to simulate a heavy load on the server. The following table was generated using simulated clients, repeatedly calling the name service API’s with various random requests. To assure that maximum load was placed on the server, pwgrd was disabled on the clients. It is important to note here that with pwgrd enabled, performance would have been much higher.
LDAP-UX Integration Performance and Tuning Guidelines Glossary DNS Domain Name System. A highly distributed directory service designed to efficiently serve a host/address database. Index A sorted (usually a binary b-tree) structure of keys, used to quickly reference information based on that key Name Service Provides information about objects to applications via name service APIs. As an example, DNS is a name service system that supports the gethostent() family of calls.
Appendix A dirload Tool The script on the following page can be used to monitor load on your directory server for an extended period of time. To install this file on your directory server, cut and paste the script below. It will be saved under /tmp/dirload. This script is designed to monitor load from LDAP-UX clients. It assumes that only LDAP-UX clients are accessing the directory server being measured. It does not make an accurate measurement of requests from other types of applications.
LDAP-UX Integration Performance and Tuning Guidelines Appendix B DirectoryMark5 Search Performance The following table is an unofficial estimate of Netscape Directory Server v6.02 search performance on selected HP platforms. If your platform is not listed, it can roughly be interpolated based on the speed of the processor. Example: Suppose you have a 550mhz A-Class with 2 CPUs. The formula would be to use the results from the A-Class 440 MHZ.
Appendix C Sample Client Data The following table represents the number of name service requests generated by a single “typical” client. This data was collected over a 24-hour period on production systems in the LDAP-UX development lab at HP. We should aspect more data cached if we have ldapclientd cache daemon running. 250 200 150 100 50 Time of Day Maximum requests in 10 minute period: Estimate maximum requests per second: Average requests per second: 196 0.326667 0.
LDAP-UX Integration Performance and Tuning Guidelines Appendix D Sample ldapclientd.conf configuration Following are example of parameters that are tunable in the ldapclientd.conf file. # ldap client daemon configuration. Administrator can set these values in second to tune the poscache and negcache.
