Previous      Contents      Index      Next
Sun Java[TM] System Identity Manager 7.0 Tuning, Troubleshooting, and Error Messages

Chapter 1
Performance Tuning

This chapter provides information to help you optimize Identity Manager performance. This information includes a description of tools, methodologies, and references that you can use to improve performance and a list of resources you can use to debug performance-related issues.

Note	Be aware that the tunings described in this chapter are only guidelines. To optimize your deployment, you may have to modify some of these tunings. Where noted, be sure to validate tunings before applying changes in a production environment. The XPRESS set method is being deprecated as of Identity Manager 7.0. You should use putmap, setlist, and setvar methods.

This chapter is organized into the following sections:

Optimizing the J2EE Environment
Optimizing the Database Repository
Optimizing the Identity Manager Product
Optimizing the General XML
OS Kernel Tunings
Debugging Performance Issues

---

Optimizing the J2EE Environment

This section describes methods you can use to optimize the J2EE environment, including

Overview
Tuning the JVM
Tuning the HTTP Container

Overview

The performance increases described in Table 1-1 were observed during a series of experiments that resulted in a considerable increase in throughputs for the use cases tested. These increases are attributed to JVM sizing and switches that affected garbage collector behavior and HTTP container tuning:

Table 1-1   Performance Increases in Throughputs

Scenario/Use Case	Users	Throughput Increase
Create user	100	20% – 25%
Approve user	50	700%
	Note: In an untuned case (50 users), Out of Memory Errors occurred.
Edit user	20	10%

The JVM tuning suggestions provided in this chapter were derived using the following tools:

Adding the following flags to the server.xml file, and collecting statistics about garbage collector behavior:

Code Example 1-1  Collecting Statistics about Garbage Collector Behavior

<jvm-options> -verbose:gc </jvm-options> <jvm-options> -XX:+PrintGCTimeStamps </jvm-options> <jvm-options> -XX:+PrintGCDetails </jvm-options>

Using a data mining script called PrinGCStats to analyze the collected statistics. The PrinGCStats script summarizes the garbage collector activity from detailed Garbage Collector logs.

Note	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 PrintGCStats script, and Using collected statistics to derive optimal JVM tunings, go to: http://java.sun.com/developer/technicalArticles/Programming/turbo

Tuning the JVM

To improve JVM performance:

Use JVM 1.4.2 or higher.
If you deployed Identity Manager on Sun Java System Application Server, you can increase throughput by adding the garbage collection elements shown in Code Example 1-2 to the deployed Identity Manager instance server.xml file:

Code Example 1-2  Adding Elements to the server.xml File

<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 tunables that affect the sizes of various thread pools and connection queues maintained by the HTTP container. Most of these tunables 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), because the static content of most Identity Manager deployments is not projected to change frequently.

These File Cache settings are available on the File Cache Configuration page. To access this page, select the File Caching tab on the Web-based Admin Console for the HTTP server node.

Tuning the HTTP Container

You can use the perfdump script to gather HTTP container statistics. Use these statistics to identify potential bottlenecks in application server HTTP container performance and to determine appropriate sizings for the different thread and connection pools and queues in the HTTP container.

Note	For information about using the perfdump script, go to: http://docs.sun.com/app/docs/doc/817-2157-10

---

Optimizing the Database Repository

You can implement the following tuning suggestions (as appropriate) to optimize a database repository:

If you are using a data source, set the connectionPoolDisable attribute to true in the RepositoryConfiguration object to disable automatic internal connection pooling in the Identity Manager repository:

<RepositoryConfiguration connectionPoolDisable=’true’>

If you use an Oracle database repository, you might encounter a problem with object table fragmentation because Identity Manager uses LONG (rather than LOB), data types by default. Using LONG data types result 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. After importing, you must stop and then restart the database.
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

Suggestions for optimizing Identity Manager are organized into the following areas:

General
Task Bar
Provisioner
Session
Workflow
ManualAction and WorkItem
Forms
Resource Query
Reconciliation

General

In general, you can optimize Identity Manager performance by

Turning off any form of tracing (such as workflow, userform, and java classes).
Using the Java Runtime Analysis Toolkit (JRat) to identify potential performance bottlenecks — especially if your deployment uses custom java classes. For more information about JRat, go to:

http://jrat.sourceforge.net/

Checking the README files in new Identity Manager service or install packs to see if any performance improvements have been made to the product. If so, schedule an upgrade.

Task Bar

The Administrator Interface task bar displays links to all previously performed provisioning tasks, which causes the interface to render more slowly when there are a large number of tasks.

To improve interface performance, remove the taskResults.jsp link from all JSPs by deleting the <List>...</List> element from the UserUIConfig object.

Code Example 1-3 illustrates removing the <List>...</List> entries within <TaskBarPages>:

Code Example 1-3  Modifying the UserUIConfig Object

<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

To improve provisioner performance:

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 to control the number of concurrent operations (such as reprovisioning) a user can execute for a specific task.

Code Example 1-4 limits user bob to running one reprovisioning task at a time:

Code Example 1-4  Limiting Concurrent Operations

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

To enforce the task quota, you can reference poolName in a TaskDefinition using the following 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 the Configurator user for reconciliation and ActiveSync tasks. Configurator 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

You can use the following methods to optimize workflow:

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:

Code Example 1-5  Restricting the Number of Resources

<Argument name=’TargetResources’>   <list>     <string>resource name[| #]</string>   </list> </Argument>

Note	In Code Example 1-5, [| #] is an optional parameter that you can use 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:

<setvar name=’myLargeList’></null></setvar>

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 (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
Use <setvar name=’tempVar’/> to clear the variable after ManualAction
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.

Use one of the following methods to cache query results:

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)

Note	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 might have to wrap an object instead of using the <o></o> element.

---

OS Kernel Tunings

Chapter 6 of the Sun Java Application Server Performance Guide for 7.1EE indicates doing some tunings in /etc/system and some using ndd /dev/tcp.

For Linux OS tunables, refer to the 7.0 Performance guide.

---

Debugging Performance Issues

The following debugging pages, available from the Administrator Interface, provide helpful information for optimizing performance:

debug/callTimer.jsp – Provides start and stop functions, and the ability to export and import metrics. Use this page to track bottlenecks to specific methods and invoked APIs.
debug/Show_Memory.jsp – Shows the amount of total and free memory. Use this page to determine whether you have sufficient memory allocated to the JVM when using memory-intensive functionality such as Reconciliation.
debug/Show_Timings.jsp – Provides an option to clear results, but is always “on.” Use this page to quickly detect and assess hotspots at a method level.
debug/Show_Threads.jsp – Shows which processes are running. Use this page to verify that automated processes (such as reconciliation or ActiveSync) are running.
debug/Show_JDBC.jsp – Shows connection pool statistics, if you are not using a data source.
debug/Show_Trace.jsp – Use to configure java class tracing on ANY class included with the Identity Manager installation.

Previous      Contents      Index      Next

---

Part No: 819-6130-10.   Copyright 2006 Sun Microsystems, Inc. All rights reserved.