Tuning Reconciliation

The Reconciler is the Waveset component that performs reconciliation. This section suggests methods for improving Reconciler performance, including:

• General Suggestions for Tuning Reconciliation

• Tuning the Reconciler Server Settings

• Tuning Reconciliation for Multiple Resources

General Suggestions for Tuning Reconciliation

In general, you can improve Reconciler performance if you do the following:

• Avoid using the Configurator user for reconciliation tasks. The Configurator has access to unlimited tasks and can monopolize available resources, which adversely affects concurrent processes.

  Instead, use a streamlined, minimal user for reconciliation and Active Sync tasks. Because the subject executing the task is serialized as part of the task, a minimal user takes less space, or overhead, for each task and update in the repository.

• Use information on the Reconciler status page (debug/Show_Reconciler.jsp) to decide which settings to adjust based on queue sizes, available system resources, and performance benchmarks. Be aware that these settings are dependent on the environment.

  ---

  Note –

  The Reconciler JMX MBean provides much of the information in Show_Reconciler.jsp, and shows a processing rate estimate.

  ---

• Use the System Memory Summary page (debug/Show_Memory.jsp) to see how much total and free memory is available. Reconciliation is a memory-intensive function, and you can use this information to determine whether there is sufficient memory allocated to the JVM. You can also use this page to launch garbage collection or to clear unused memory in the JVM for investigating heap usage.

• When you assign user forms to proxy administrators who are performing reconciliations, keep the user forms as simple as possible and only use essential fields. Depending on the schema map, including a field that calculates the waveset.organization attribute is generally sufficient.

  ---

  Note –

  Administrators who need to view or edit the Waveset schema for Users or Roles must be in the IDM Schema Configuration AdminGroup and must have the IDM Schema Configuration capability.

  ---

• Use per-account workflows judiciously. The reconciliation process does not start provisioning tasks for performance reasons by default.

  If you must use a per-account workflow task, edit the reconciliation policy to limit the Reconciler’s automatic responses to events of interest only. (See the Situation area of the Edit Reconciliation Policy page.)

Reconciliation of a resource goes through two phases. In the first phase, Waveset gets a list of all users in its internal repository that are known to have accounts on the resource. This first phase does not involve the physical resource at all, and typically happens very quickly.

The second phase requests a list of all accounts from the resource, and then processes those accounts; potentially linking them to users or even creating new users. Performance of the second phase, indicated as reconciling accounts in the resource status message, is proportional to the speed of the resource and the number of worker threads. You can compensate for a slow resource by adding more worker threads; assuming the resource can handle more concurrent AccountGet operations.

There is a JMX MBean for each resource that shows the average, minimum, and maximum response times for each resource operation. Reconciliation phase two involves lots of Account_Get operations, so the average time for each Account_Get strongly influences the overall reconciliation performance. To compensate for resources with longer Account_Get times, use more worker threads. However, because the same number of worker threads are used for all resources, setting a maximum worker thread too high might overwhelm the Waveset object repository on faster resources.

Tuning the Reconciler Server Settings

Although the default settings are usually adequate, you can sometimes improve Reconciler performance if you adjust the following settings on the Edit Server Settings page:

• Parallel Resource Limit. Specifies the maximum number of resource threads that the Reconciler can process in parallel.

  Resource threads allocate work items to worker threads, so if you add additional resource threads, you might also have to increase the maximum number of worker threads.

• Minimum Worker Threads. Specifies the number of processing threads that the Reconciler always keeps open.

• Maximum Worker Threads. Specifies the maximum number of processing threads that the Reconciler can use. The Reconciler starts only as many threads as the workload requires, which places a limit on that number. Worker threads automatically close if they are idle for a short duration.

During idle times, the threads stop if they have no work to do, but only down to the minimum number of threads specified. As the load increases, the Reconciler adds more threads until the maximum number of threads is reached. The Reconciler never has less than the minimum number of threads or more than the maximum.

Generally, more threads allow more concurrency. However, at some point, too many threads can put too much load on the machine or just do not provide additional benefit. Because the worker threads are typically reading and writing User and Account objects, having too much concurrency might overload the Waveset repository RDBMS.

Recommending generic, optimal settings is not possible because deployments are so different. Reconciler settings must be adjusted differently for each deployment environment.

To Change the Reconciler Server Settings

Perform the following steps to change the Reconciler server settings:

1. Log into the Administrator interface.

2. Click the Configure -> Servers -> Reconciler tabs.

3. When the Edit Server Settings page is displayed, adjust the settings as necessary.

   See Editing Default Server Settings for more information.

Tuning Reconciliation for Multiple Resources

If you are configuring reconciliation for multiple resources in Waveset, you have several options:

• All of the resources on the same server, all at the same time.

  This option is the most efficient from the Waveset perspective, but if you have many resources (for example more than 20), you are likely to experience Java resource issues.

• All of the resources on the same server, each at a different time.

  This option is easier on Java resource loading, but puts a significant burden on your schedule configuration.

• Each resource on a different server, all at the same time.

  This option minimizes elapsed time, but increases the number of servers.

An ideal solution does not exist for this configuration because deployments are so different. You might have to mix and match these options to find an acceptable solution for your deployment.

Preparing a usage survey, based on the business reasons behind this functionality, might help you decide how to proceed.

Address these questions:

• Why are you reconciling these resources?

• Do you have the same the goal for each of these resources?

• Are each of these resources equally important or critical?

• Must all resources be reconciled on the same schedule, or can you spread out the reconciliations?

• How often must each resource be reconciled?

Also, remember that the reconciliation server does not have to be one of the pools that handles web traffic. You can add a server that you never interact with directly because this server exists solely for transaction processing. Having a server dedicated to transaction processing might make the first option more attractive for very large systems.