Page 18 IBM Tivoli Identity Manager Performance Tuning Guide
7 Best practices The IBM Tivoli Identity Manager product can be set up and configured in many ways. The following are
some suggested best practices to help guide you in setting up your environment.
• Each agent modifies the LDAP schema by adding new attributes to support a new service.
These attributes are created without indexes, and for services that service thousand of users, a
large benefit can be achieved by adding indexes to attributes with many members.
• Complicated provisioning policies can result in complicated directory and database queries with
poor performance. Policies with small numbers of roles and services will perform best.
• Dynamic roles affect people in a given scope, either one-level or subtree. When a person object
within that scope is modified or added, that role must be re-evaluated. This is true for every
dynamic role in the system. For instance, if there are three dynamic roles with subtree scope and
a person object within that scope is updated, all three dynamic roles will be re-evaluated. For this
reason, it is recommended that you limit the number of dynamic roles, either by number or by
scope, that affect people that are modified frequently. It doesn’t matter if the dynamic role ends
up enrolling the person or not, the evaluation itself is the performance-impacting overhead.
• Limiting the scope (via placement within the organizational tree) and number of ACIs will increase
performance by requiring fewer evaluations. When doing a person search via the APIs, be sure to
limit the scope of your search to be as narrow as possible to avoid the system evaluating more
ACIs than necessary.
• When enabling WebSphere global security, do not enable Java 2 security unless it is required for
your environment. Enabling WebSphere global security automatically enables Java 2 security
unless it is explicitly disabled. Having Java 2 security enabled can cause a significant
performance degradation to IBM Tivoli Identity Manager.