administration mode

Performance Peek blog

Is you Domino LDAP service under stress ? »

CHRISTIAN DENCKER - JAN 16, 2015 (07:18:38 PM)

To tell if the Sametime Resolve task in an LDAP environment is under stress, you can enable debug. The following debug parameter can be put in the Sametime.ini to enable LDAP tracing:


With this debug in place, a file called StLdap_StResolve*.txt will be created in the \trace directory. This file contains all of the name lookup requests that are sent to the LDAP server. Information about the state of the STResolve operations is also logged. When the incoming request rate is greater than the processing capacity of the STResolve service, then the
following message will be logged:

LDAP 08/Mar/05, 16:37:33 Warning: 10 operations waiting for response. Will not request new perations until at most 5 are left

This message is purely informational and indicates that the maximum number of requests submitted to the LDAP server has been reached. The STResolve task will stop sending requests until the lower threshold is met. In the message above, the maximum number of in flight requests is 10 and the minimum threshold is 5. If the size of the queue continues to grow, a low efficiency message will be logged to the trace file:

LDAP 08/Mar/05, 16:38:33 Warning: low efficiency [2 iterations]
Ø comments disabled

Domino LDAP Performance »

CHRISTIAN DENCKER - JAN 16, 2015 (07:03:04 PM)

Performance optimization

To allow the Domino LDAP severs handle the load coming through the LDAP protocol from Sametime Community Servers, at least the following steps should be followed on the Domino LDAP servers:



Every address book available in the Domino LDAP must be full text indexed.(FTI)


Domino LDAP cache is disabled by default. It must be manually enabled in notes.ini on the Domino LDAPs:


For Domino LDAPs with lots of RAM which are dedicated for Sametime, the size can be set higher:


Domino LDAP server must be restarted for the changed to take affect.

Note that only hits are added to the Domino LDAP cache. Searches that don't find a match in the cache slow the LDAP greatly, meaning that the number of searches unmatched in the Directory should be as minimal as possible. The ways to achieve this are discussed in the “Optimizing Sametime searches performance” section.

Number of worker threads
Domino LDAP uses 40 worker threads by default for handling LDAP requests. The number should be raised to 80 in notes.ini:


For Domino LDAPs with lots of RAM which are dedicated for Sametime, the size can be set higher:


Domino LDAP server must be restarted for the changed to take affect.

DA.nsf considerations
Unnecessary secondary address books pointed by DA.nsf on the Domino LDAP servers must be removed from DA.nsf or be disabled for LDAP searches.

The most common reason for slow database performance »

CHRISTIAN DENCKER - OCT 12, 2011 (11:22:42 PM)


The most common reason for slow database performance is based on this "equation":

Database Performance = ((number of users) x (size of database) x (number of views) x (frequency of document updates) x (2 x (network latency))  / (processor cores)) x (AVG I/O DiskQueLenght)


Now as you can see the DiskAccess time, or the abillity of your disk's has a major impact og your database performance.



Ø comments disabled

Determine the number of a Domino Serveres Mail.Box »

CHRISTIAN DENCKER - MAR 14, 2011 (02:59:32 PM)


By calculating the number of access conflicts as a percentage of total accesses, you can determine whether a server will benefit from the addition of another MAIL.BOX.

In general, the number of access conflicts should be no more than two percent of the total number of accesses. However, because some access conflicts may result from unusually high peak loads, there's no need to eliminate all access conflicts. Only when the percentage of access conflicts remains consistently greater than 2 percent is an additional MAIL.BOX database warranted.

Note Mailbox statistics are available only on servers where two or more MAIL.BOX databases are configured. You must restart the server to put into effect any changes to the number of mailboxes.


Ø comments disabled

Potential Security Vulnerability in domino 8.0.x and 8.5.x »

CHRISTIAN DENCKER - MAR 3, 2011 (09:47:42 PM)


Under 1 specific Domino Configuration,"Deleted Users" gets deleted from the "Deny Access group", thus making it possible for "Terminated Users" with valid's to gain access to you Domino Domain.

Domino or any program that runs as a part of the Domino server, must not delete names from the "Deny Access Groups", under any circumstance!

Only administrators should be allowed to delete names from deny access groups.

Currently Domino can remove names from the Deny Access list groups automatically!

For example, it happens if the "Action" setting in the Domino Directory ACL is not set to "Do not modify names fields". When an user is deleted, at the end of the AdminP sequence of requests the name is removed from the group. (even if the "Add deleted user to Deny Access Group" option is set - the user is added, and then removed).

This leads to a security breache, as deleted users gain not authorized access to the server, with a valid file.

Secondary aspects of the problem are administrators unaware of the security mis-configuration (missing names in the group and wrong "Action" setting in ACL), and the difficulty in restoring the names in the group once they have been deleted (for example if the problem is discovered after a long time, or backups are lost).

IBM should alter the Domino 8.x behavior so that names are never automatically removed from the deny access lists, whatever the configuration settings.

The SPR number is SSAI8EKC5N, and the corresponding APAR number is LO58885.

Ø comments disabled

Continue reading...