nsslapd-threadnumberis set to 6 or 8 (on a Montvale-based test bed with 8 CPUs). Based on the performance test experiment, the best exact search performance occurs only when nsslapd- threadnumber is tuned close to the number of CPUs. This performance characteristic is verified with up to 8 CPUs on a Montvale-based test bed.

When tuning this parameter, consider the following:

•If the directory only serves non-SSL based search requests, tune nsslapd-threadnmberstarting from where it equals the number of CPUs.

•If the directory needs to handle time-consuming operations that require threads to be blocked for a long time, such as SSL based searches, then tune up the nsslapd-threadnumber.

•If a large number of clients are concurrently requesting connections, tune up the nsslapd- threadnumber.

•If you experience low CPU utilization under a heavy load, or slow response time, try to tune up nsslapd-threadnumberand see if performance improves.

Figure 1: Performance based on nsslapd-threadnumber

operations/sec

25000

20000

15000

10000

 

 

 

 

 

 

 

 

 

2 dual-core CPUs

 

 

 

 

 

 

 

 

 

 

 

5000

0

0

20

40

60

80

100

120

140

number of threads

nsslapd-dbcachesize

The nsslapd-dbcachesizeparameter is described as follows in the HP-UX Directory Server configuration, command, and file reference:

nsslapd-dbcachesize

This performance tuning attribute specifies the database index cache size. It is one of

the most important values for controlling how much physical RAM the directory server uses. This is not the entry cache. This is the amount of memory the Berkeley database backend will use to cache the indexes (the .db4 files) and other files. This value is passed to the Berkeley DB API function set_cachesize. If automatic cache resizing is activated, this attribute is

6