Sun Java[tm] System Identity Manager 6.0 Tuning, Troubleshooting, and Error Messages 2005Q4M3 |
1
Performance Tuning
This chapter provides information and guidelines for tuning Identity Manager performance. This information is organized into the following sections:
These sections include suggested tools, methodologies, and references for increasing performance and a list of resources for debugging performance-related issues.
Notes
Optimizing the J2EE EnvironmentRecommendations for improving JVM performance include:
- Use JVM 1.4.2 or higher.
- If you are running JDK 1.4.1 or higher, remove the Cryptix jars
(cryptix-jceapi.jar and cryptix-jce-provider.jar) from the idm\WEB-INF\lib directory.- If you deployed Identity Manager on Sun Java System Application Server, add these garbage collection elements to the deployed Identity Manager instance server.xml file to increase throughput:
<jvm-option> -server </jvm-option>
<jvm-option> -XX:+DisableExplicitGC </jvm-option>
<jvm-option> -XX:+UseParNewGC </jvm-option>
<jvm-option> -XX:+UseConcMarkSweepGC </jvm-option>
<jvm-option> -Xms1024m -Xmx1024m </jvm-option>
<jvm-option> -XX:SurvivorRatio=128 </jvm-option>
<jvm-option> -XX:NewSize=300m -XX:MaxNewSize=300m \
</jvm-option>
<jvm-option> -XX:MaxTenuringThreshold=0 </jvm-option>
<jvm-option> -XX:CMSInitiatingOccupancyFraction=60 \
</jvm-option>- Sun Java System Application Server exposes a number of tuneables that affect the sizes of various thread pools and connection queues maintained by the HTTP container. Most of these tuneables are, by default, set for a concurrent user load of 300 users or fewer.
For an expected peak load of more than 300 users, modify these settings to increase performance:
- For the HTTP listeners configured for the instance where Identity Manager is deployed, edit the listener definition element in the server.xml file. Set the number of acceptor threads to:
(Number of active CPUs on the host) divided by
(Number of active HTTP listeners on the host)For example:
<http-listener id=”http-listener-1” \
address=”0.0.0.0” port=”80” \
acceptor threads=”Calculated Acceptor Threads” ...>- Edit the file cache settings for static content. Set the Maximum Age of contents within the file cache before they are reloaded to a high number (for example, number of seconds in 24 hours), since the static content of most Identity Manager deployments is not projected to change frequently.
To access the File Cache tunings, go to the File Cache Configuration page. You can access this page from the File Caching tab of the Web-based Admin console for the HTTP server node.Tools for Tuning the JVM
Sun JVM tuning recommendations derive from performance increases in throughputs for a series of tested use cases, as shown in the following table.
Scenario/Task
Users
Throughput Increase
Create user
100
Between 20 and 25%
Approve user
50
700%
Edit user
20
10%
Increases illustrated in this table are due to JVM sizing and switches that affect garbage collector behavior, and HTTP container tuning.
Suggested tunings for the JVM resulted from:
- Collecting statistics about garbage collector behavior by adding these flags to the server.xml file:
<jvm-options> -verbose:gc </jvm-options>
<jvm-options> -XX:+PrintGCTimeStamps </jvm-options>
<jvm-options> -XX:+PrintGCDetails </jvm-options>- Analyzing the collected statistics by using a data mining script called PrinGCStats. This script summarizes the garbage collector activity from the detailed garbage collector logs.
You can download the PrintGCStats script from the Sun Java Developers site:
http://java.sun.com/developer/technicalArticles/Programming/turbo/PrintGCStats.zip
For more information about using the script, and about how to use the collected statistics to derive optimal JVM tunings, go to:
http://java.sun.com/developer/technicalArticles/Programming/turbo
Tools for Tuning the HTTP Container
You can analyze data gathered from the perfdump script to identify potential bottlenecks in application server HTTP container performance, and to derive appropriate sizing for thread and connection pools and queues in the HTTP container.
For information about how to use perfdump to gather HTTP container statistics, and how to use the gathered statistics to tune the HTTP container, go to:
http://docs/sun.com/
Optimizing the Database RepositoryImplement these repository optimization suggestions, as appropriate:
- If you are using a data source, be sure you turn off the Identity Manager connection pool by setting the following Waveset.property attribute to true:
com.waveset.repository.ConnectionPoolDisable=true
- If you use an Oracle database repository, you may encounter a problem with object table fragmentation because Identity Manager uses LONG, rather than LOB, data types by default. This results in large amounts of “unallocated” extent space, which cannot be made into usable space.
To mitigate this problem:
- Take EXPORT dumps of the Object table, and then reimport to free up unallocated extent space. You must first stop, and then restart the database after import.
- Use LOB data types and use DataDirect Technologies’ Merant drivers, which provide a standard LOB implementation for Oracle.
- Use Locally Managed Tablespaces (LMTs), which offer automatic free space management. LMTs are available in Oracle 8.1.5.
- Use RepoIndexAttrs to determine which extended attributes are stored inline in the UserObj table for quick searching. This is especially useful for correlation keys and display data.
QueryableAttrNames has to perform a join of userattr and userobj tables, which is not as fast.
Edit the UserUIConfig object to add these lines:
<RepoIndexAttrs>
<List>
<String>MemberObjectGroups</String>
<String>lastname</String>
<String>firstname</String>
</List>
</RepoIndexAttrs>
Optimizing the Identity Manager ProductIdentity Manager product optimization suggestions are divided among these areas:
General
Some general suggestions for optimizing Identity Manager include:
- Ensure that any form of tracing (workflow, userform, java classes, and so forth) is turned off.
- If you are not using the latest service pack or install pack, be sure to examine the readme files for the newer packs to see if any performance improvements have been made to the product. If so, schedule an upgrade.
- Consider using JRAT to track down performance bottlenecks, especially when your deployment uses custom java classes. Go to:
http://jrat.sourceforge.net/
Task Bar
The Administrator Interface task bar shows links to all previously performed provisioning tasks. This causes the interface to render more slowly when there are a large number of tasks.
To improve interface performance, you can remove the taskResults.jsp link from all JSPs. To do this, modify the UserUIConfig object and remove the <List>...</List> element.
In the following example, you would remove the <List>...</List> entries within <TaskBarPages>:
<TaskBarPages>
<List>
<String>account/list.jsp</String>
<String>account/find.jsp</String>
<String>account/dofindexisting.jsp</String>
<String>account/resourceReprovision.jsp></String>
<String>task/newresults.jsp</String>
<String>home/index.jsp</String>
</List>
</TaskBarPages>Provisioner
Recommendations for optimizing provisioner performance include:
- Set provisioner.maxThreads in the Waveset.properties file to control the number of simultaneous account provisioning threads, where a thread is launched for each resource operation.
In general, best performance is achieved with a value of 10. Beyond a value of 20, performance significantly degrades.
- Configure quota settings in the Waveset.properties file. This controls the number of concurrent operations, such as reprovisioning, that can be executed by a user for a specific task.
In the following example, user bob is limited to running one reprovisioning task at a time:
Quota.poolNames=ReProvision,Provision
Quota.pool.ReProvision.defaultLimit=1
Quota.pool.ReProvision.unlimitedItems=Configurator
Quota.pool.ReProvision.items=bob,jan,ted
Quota.pool.ReProvision.item.bob.limit=1You can reference poolName in a TaskDefinition to enforce the task quota, in the format:
<TaskDefinition ... quotaName=’{poolName}’..>
Set the quota higher for proxy administrators who perform reconciliation or ActiveSync tasks. Most users launch only one task at a time.
Note Avoid using Configurator for reconciliation and ActiveSync tasks. This user has access to unlimited tasks and can monopolize available resources, which adversely affects concurrent processes.
Session
Identity Manager maintains a least recently used (LRU) cache of authenticated sessions for use by authenticated users. By using existing, authenticated sessions, you can speed repository access for objects and actions that require a session.
To optimize authentication pool size, change the session.userPoolSize value in the Waveset.properties file to the maximum number of expected, concurrent user sessions on the server.
Note Do not exceed a value of 100, as performance degrades significantly at higher values.
Workflow
Recommendations for optimizing workflow include:
- Simplify default workflows to improve processing time (especially for bulk processing actions such as ActiveSync, bulk actions, and reconciliation) by removing the callout to the Approval subprocess.
- Be sure that no infinite loops exist in your workflows. In particular, ensure break flags are updated and properly checked in the loops that exist in approval subprocesses.
- Put fetched objects into a variable for use later if you must call out to the repository for the same object multiple times.
Using a variable is necessary because Identity Manager does not cache all objects.
- Specify TargetResources options in WorkflowServers checkoutView to restrict the number of resources that are queried for account information. For example:
<Argument name=’TargetResources’>
<list>
<string>resource name[| #]</string>
</list>
</Argument>
Note In the preceding example, [| #] is an optional parameter that is used when more than one account exists on a particular resource; otherwise, the resource name is sufficient.
- Clear unnecessary view variables left by forms, especially large maps and lists; for example:
<set name=’myLargeList’></null></set>
View is copied multiple times in a TaskInstance object, so large views greatly increase the size of TaskInstances.
- Use resultLimit (in seconds) in the TaskDefinition, or set it during task execution to quickly dispose of completed tasks. Large numbers of TaskInstances impact:
- Set the following options as needed:
- delete (this is the preferred option): Causes an older TaskInstance of the same name to be deleted before the new task begins execution.
- wait: Suspends the current TaskInstance until the older TaskInstance is deleted or expired due to reaching its resultLimit.
- rename: Inserts a time stamp into the TaskInstance name to avoid naming collisions.
- terminate: Deletes an older TaskInstance of the same name.
Any currently executing TaskInstances of the same name are killed.ManualAction and WorkItem
Performance recommendations in this area include:
- Reduce the size of work items.
By default, ManualAction creates a work item, and then copies all variables in the task context into WorkItem.variables.
Use ExposedVariables to restrict the variables assimilated back into WorkItem. For example:
<ExposedVariables><List><String>user ...
Use EditableVariables to restrict the variables assimilated back into the task from WorkItem. For example:
<EditableVariables><List><String>user ...
- Speed UI response time by making changes to the confirmation page and background processing:
- Do not specify synchronous execution (syncExec=’true’) for the last page in a wizard workflow. If set to true, the task will run to completion when the user executes the task. The interface will hang until the task completes or encounters another stopping point (another ManualAction).
Forms
Recommendations for optimizing forms performance include:
- Perform “expensive” queries only once, if possible. You can minimize such queries by:
- Use <defvar> for calculations that should be performed on initial display and with each refresh.
- Specify TargetResources in Admin forms to fetch only specific resources for editing. See the earlier section, titled Workflow, for more information.
Resource Query
To increase resource query performance, implement the query using FormUtil.getResourceObjects.
Cache query results by using the following methods:
- getResourceObjects(Session session, String objectType, String resID, Map options, String cacheList, String cacheTimeout, String cacheIfExists)
- getResourceObjects(String subjectString, String objectType, String resId, Map options, String cacheList, String cacheTimeout, String clearCacheIfExists)
Notes
- Set cacheTimeout in milliseconds.
- Restrict searches to specific searchContext, if applicable.
- Return the minimum number of attributes in options.searchAttrsToGet
Reconciliation
To optimize reconciliation performance:
- The user form assigned to the proxy administrator that performs reconciliation should be as simple as possible, including only essential fields. Often, it is sufficient to include a field that calculates the waveset.organization attribute (depending on the schema map).
- Use per-account workflow judiciously. By default, the reconciliation process does not launch provisioning tasks for performance reasons. If you must use a per-account workflow task, edit the reconciliation policy to limit automatic responses by the reconciler only to events of interest. (See the Situation area of the Edit Reconciliation Policy page.)
Optimizing the General XMLIn general, use static XMLObject declarations if possible. For example, use:
Depending on the context, you may also need to wrap an object instead of using the <o></o> element.
Debugging Performance IssuesThe following debugging pages, available from the Administrator Interface, provide helpful information for optimizing performance:
- debug/callTimer.jsp – This page provides start and stop functions, and the ability to export and import metrics. It is useful for tracking bottlenecks down to specific methods and invoked APIs.
- debug/Show_Memory.jsp – This page shows the amount of total and free memory. You can use this page to determine whether the amount of memory allocated to the JVM is sufficient when you use memory-intensive functionality such as Reconciliation.
- debug/Show_Timings.jsp – This page provides an option to clear results, but is always “on.” It allows for quick assessment at a method level for detection of hotspots.
- debug/Show_Threads.jsp – This page shows which processes are running. You can use this page to ensure that an automated process is running, such as reconciliation or ActiveSync.
- debug/Show_JDBC.jsp – This page shows connection pool statistics, if you are not using a data source.
- debug/Show_Trace.jsp – Use this page to configure java class tracing on ANY class included with the Identity Manager installation.