Performance Tuning

1 Performance Tuning

This chapter provides information and guidelines for tuning Identity Manager performance. This information is organized into the following sections:

Optimizing the J2EE Environment

Optimizing the Database Repository

Optimizing the Identity Manager Product

Optimizing the General XML

Debugging Performance Issues

These sections include suggested tools, methodologies, and references for increasing performance and a list of resources for debugging performance-related issues.

Notes

Provided recommendations serve only as guidelines. You may need to modify one or more tunings to optimize your deployment.

Where suggested, you should use tools to validate tuning before applying changes in a production environment.

Optimizing the J2EE Environment

Recommendations 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 Repository

Implement 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 Product

Identity Manager product optimization suggestions are divided among these areas:

General

Task Bar

Provisioner

Session

Workflow

ManualAction and WorkItem

Forms

Resource Query

Reconciliation

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=1

You can reference poolName in a TaskDefinition to enforce the task quota, in the format:

Set the quota higher for proxy administrators who perform reconciliation or ActiveSync tasks. Most users launch only one task at a time.

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>

[| #]

Clear unnecessary view variables left by forms, especially large maps and lists; for example:

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:

Display of taskResults.jsp on footers, and on some JSPs in the Administrator Interface

Display of all tasks JSPs

Querying TaskInstances for task renaming

Database size

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:

Create a confirmation ManualAction or background ManualAction, owned by another user such as Configurator.

Set timeout=’-5’ (5 seconds) and ignoreTimeout=’true’ to avoid an error message if a user submits an action after the task is executing and the work item is deleted.

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:

Using <Field> <Default> to execute and store query results

Referencing values in later fields by using field names

If using a custom task:

Calculate the value in the task before ManualAction, and then store the value in a task variable.

Reference variables in a form by using :variables.tmpVar

Clear the variable after ManualAction by using
<set name=’tempVar’/>

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)

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 XML

In general, use static XMLObject declarations if possible. For example, use:

<List> instead of <list>

<String> instead of <s>

<Map><MapEntry ...></Map> instead of <map>

Depending on the context, you may also need to wrap an object instead of using the <o></o> element.

Debugging Performance Issues

The 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.

Previous Contents Index Next

Previous Contents Index Next
Sun Java[tm] System Identity Manager 6.0 Tuning, Troubleshooting, and Error Messages 2005Q4M3