Filter
Top Products
<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