Configuring Worker Threads and Backend Connections

Directory Proxy Server allows you to configure how many threads the server maintains to process requests. You configure this using the server property number-of-worker-threads, described in number-of-worker-threads(5dpconf). As a rule of thumb, try setting this number to 50 threads plus 20 threads for each data source used. To gauge whether the number is sufficient, monitor the status of the Directory Proxy Server work queue on cn=Work Queue,cn=System Resource,cn=instance-path,cn=Application System,cn=DPS6.0,cn=Installed Product,cn=monitor. If you find that the operationalStatus for the work queue is STRESSED, this can mean thread-starved connection handlers are unable to handle new client requests. Increasing number-of-worker-threads may help if more system resources are available for Directory Proxy Server.

The number of worker threads should also be appropriate for the number of backend connections. If there are too many worker threads for the number of backend connections, incoming connections are accepted but cannot be transmitted to the backend connections. Such a situation is generally problematic for client applications.

To determine whether this situation has arisen, check the log files for error messages of the following type: "Unable to get backend connections". Alternatively, look at the cn=monitor entry for load balancing. If the totalBindConnectionsRefused attribute in that entry is not null, the proxy was unable to process certain operations because there were not enough backend connections. To solve this issue, increase the maximum number of backend connections. You can configure the number of backend connections for each data source by using the num-bind-limit, num-read-limit and num-write-limit properties of the data source. If you have already reached the limit for backend connections, reduce the number of worker threads.

If there are not enough worker threads for the number of backend connections, so much work can pile up in the server's queue that no new connections can be handled. Client connections can then be refused at the TCP/IP level, with no LDAP error returned. To determine if this situation has arisen, look at the statistics in the cn=monitor entry for the work queue. In particular, readConnectionsRefused and writeConnectionsRefused should remain low. Also, the value of the maxNormalPriorityPeak attribute should remain low.