Managing Sametime LDAP internal queues

You can manage advanced configuration settings for the maximum and minimum (MAX/LOW) number of LDAP requests that are pending per connection in the pending queue.

The following settings can be specified in the [Directory] section of the sametime.ini file.

  • ST_DB_LDAP_PENDING_MAX

    Defines the maximum number of LDAP requests that can be pending per connection in the pending queue. Each connection is for a different type of request; whether search or bind. A Pending Resolve Request is a request that has been sent to the LDAP Server. The request is considered pending until the IBM® Sametime® Community Server receives a response from the LDAP server for that request. The Sametime Community Server sends, at most, MAX PENDING Requests to the LDAP server. After MAX Pending Requests are sent to the LDAP server on a particular connection, the Sametime Community Server does not send any additional LDAP requests on this connection until the Pending Queue Size drops to the ST_DB_LDAP_PENDING_LOW Pending Request queue size.

    For versions prior to Sametime 8.5, the value is set to 10 by default. In Sametime 8.5 and higher, the value is set to 60 by default. Any Sametime service that connects to the LDAP server uses the LOW and MAX PENDING queue.

  • ST_DB_LDAP_PENDING_LOW

    Strongly linked to the ST_DB_LDAP_PENDING_MAX setting and to the request queuing feature of Sametime. Once ST_DB_LDAP_PENDING_MAX is reached for a certain connection, new LDAP requests are not sent on this connection until the number of pending operations drops to the value set by the ST_DB_LDAP_PENDING_LOW setting.

    For versions prior to Sametime 8.5, the value is set to 5 by default. In Sametime 8.5 and higher, the value is set to 30 by default.

Table 1. Sametime.ini default values
Setting Sametime 8.5 Sametime pre-8.5
ST_DB_LDAP_PENDING_MAX 60 10
ST_DB_LDAP_PENDING_LOW 30 5

Special considerations for the PENDING MAX/LOW settings

As the PENDING MAX/LOW settings (ST_DB_LDAP_PENDING_MAX and ST_DB_LDAP_PENDING_LOW) relate to each LDAP connection, Sametime Community Server might be configured to work with multiple Connections per Sametime module, and one connection may stop handling requests while other Connections are working well.

The MAX and LOW pending queue sizes are highly dependent upon many factors, such as the resources available to the Sametime Community Server process on the host computer, the resources available to the LDAP process on the LDAP server, the network latency between the Sametime Community Server and LDAP servers, the types of generated searches, and so on. As a result, there is no golden number to guarantee the greatest efficiency for all configurations. By default, MAX and LOW are set to 10 and 5, respectively. However, advanced guidelines for optimizing LDAP configurations generally recommend 60 and 30. IBM typically recommends a size of 120 and 100 for larger corporations with high-powered LDAP servers.

Example of a Pending Low/Max Queue in sametime.ini:
ST_DB_LDAP_PENDING_LOW = 5
ST_DB_LDAP_PENDING_MAX = 10

As the Sametime Community Server receives LDAP queries (for example, Sametime Resolve or Authentication requests requiring LDAP look ups), Sametime tries to fulfill those queries by sending corresponding LDAP queries to the LDAP Server. These LDAP queries remain in the "Pending" queue until they are resolved or responded back from the LDAP Server or timed out.

If the PENDING MAX value is 10, the Sametime Community Server does not send more than ten requests to the LDAP Server initially until at least 5 requests are resolved by the LDAP Server so that the low end threshold value specified by PENDING_LOW is reached. Once the number of requests waiting for responses reaches the PENDING_LOW value, the Sametime Community Server once again starts sending more requests to the LDAP Server but repeats the cycle and limits the number of requests in flight to the LDAP Server.

Note: If the MAX and LOW sizes for the Pending Queue are not set appropriately, it is possible to overwhelm the LDAP server or artificially reduce the potential high throughput of LDAP requests sent by the Sametime Community Server to the LDAP server.