IBM G210-1784-00 manual Tuning LDAP performance, LDAP tuning guidelines

<Uri AffinityCookie="JSESSIONID" Name="/lms-ds/*.jsv"/>

<Uri AffinityCookie="JSESSIONID" Name="/lms-ds/*.jsw"/>

<Uri AffinityCookie="JSESSIONID" Name="/lms-ds/j_security_check"/> <Uri AffinityCookie="JSESSIONID" Name="/lms-ds/services/*"/>

<Uri AffinityCookie="JSESSIONID" Name="/lms-ds/servlet/AxisServlet"/> <Uri AffinityCookie="JSESSIONID" Name="/lms-ds/track"/>

Note: When you are installing customization sets for the user interface, you will also have to copy all images and style sheets to the appropriate directories on the HTTP servers.

Tuning LDAP performance

The LMS user management functions assume an LDAP directory as the primary container of user and group information. The LDAP directory contains the attributes that describe each user (for example, first name, last name, department number, organization, phone number, etc.), and it is used to authenticate each user that logs onto LMS.

When a user successfully authenticates (this process is actually handled by the WebSphere Application Server), LMS searches the user's entry in the LDAP directory and retrieves the values of all required user attributes. These attribute values are cached by LMS by storing them in the USR table of the relational databases (LMM and DS) so that they may be reused during the session. This prevents repeated queries against the LDAP directory and improves overall performance of the application.

Every time a user logs in, LMS checks if the user’s attributes have changed in the LDAP directory and updates the value stored in the USR table. If the LDAP attributes of a user changes while a user is logged in, LMS will not be aware of these changes during this session. The user will have to log in again. This is the trade-off to the cache mechanism, but not a very high price to pay for performance.

LDAP tuning guidelines

Every LDAP directory vendor supports some mechanism for performance tuning. Some vendors allow you to control caching or buffering options while some allow you to create indexes on the data in the directory. Use the following guidelines when tuning your LDAP directory to increase the performance of LMS:

1.Make sure that the user attributes that are important to LMS are defined in the LDAP section of the settings files (settings.xml, ds-settings.xml). This section contains the mappings for each of these attributes to the corresponding LDAP attributes for each vendor and object class. It is a good idea to ensure that each user’s entry in the LDAP directory is populated with the critical attributes (such as the display name). This saves LMS from having to calculate those from other attributes.

2.LMS uses the user name specified in the login screen to look up a user's entry in the LDAP directory. You should make sure that the corresponding LDAP attribute (for example, uid) is indexed by the database that powers your LDAP directory.

3.When a user logs in, LMS attempts to determine whether the user is a manager (having other people reporting to the user). If the user’s LDAP entry does not have an attribute that specifies this information (for example, isManager), LMS has to perform an additional query against the LDAP directory. This query determines if at least one other user has this user as manager. The user will only be presented with the first LMS screen after all lookups have been completed. Especially on large directories this search can be very time-consuming and significantly slow down the login process. To accelerate this you should ensure that the users’ manager attribute is indexed in the database that powers the LDAP directory. If this is not possible or does not speed up the query enough, you can defer the IsManager lookup until after the login is complete (see the details in “Deferring the IsManager lookup” below). Essentially, a separate thread performing the LDAP query is started that updates the user's entry afterwards.

Appendix A: LMS Performance and Fine-tuning Information 105