Skip Headers
Oracle® Access Manager Deployment Guide
10g (

Part Number B25344-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

2 Performance Tuning

Once you have installed and configured Oracle Access Manager, you want to be sure to get the best possible performance out of the product.

This chapter provides information for experienced Oracle Access Manager administrators on how to optimize product performance. This chapter includes the following topics:


For details about Policy Manager tuning factors for Apache Web servers, see the Oracle Access Manager Installation Guide.

2.1 Guidelines for Directory Tuning

Oracle Access Manager stores its data in an LDAP directory. When diagnosing problems that appear to be due to Oracle Access Manager, you may want to check the performance of the directory. Additionally, many performance issues can be resolved by avoiding trips to the directory, especially for write operations.

The following sections discuss these topics:

2.1.1 Check the Performance of the Directory

If directory performance is slow, it will affect the performance of the Access Server or Identity Server. See your directory vendor's documentation for details. For Oracle Internet Directory, see the chapter on performance optimization in the Oracle Internet Directory Administrator's Guide for details.

2.1.2 Directory Connection Pool Size

The Identity Server and the Access Server open a configurable number of connections to LDAP servers. If you perform a large number of time-consuming searches of user profiles, you can increase the database connection pool size to improve performance.

You configure the connection pool size in the Identity System Console or Access System Console. Note that you specify the details for connections used for accessing configuration data and policy data in configuration files, not through the System console. At startup, a number of connections are opened based on an Initial Connections setting. As needed, more connections are opened until the Maximum Connections setting is reached. Connections remain open until the Identity or Access Server shuts down or the directory server stops responding. Differences Between Configured and Actual Connection Pool Size

The number of connections that the Identity or Access Server opens to the directory is different from the number of connections that you specify in the Identity System Console or Access System Console. This is because certain connection details are picked up from configuration files. Connections are specified in the following files:

  • Connections for accessing configuration data: Three database configuration files reside in Oracle_Access_Manager_install_dir/oblix/config/ldap. The setting for the number of connections applies to each of the configuration files. The default value is 1, which means at any time at least three connections are open.

  • Connections for accessing policy information: Four locator files are used to manage policy definitions. These locators reside in Identity_Server_install_dir/oblix/config/ldap. The setting for the number of connections to be opened is on a per-locator-file basis. The default value is 1, which means at any time at least four connections are open.

  • Connections for database profiles that are created during setup: During product setup, Oracle Access Manager automatically creates one or two database profiles, depending on if the configuration base and search base are the same or disjoint. Each database profile has one instance and the number of connections is set to 1. If the database profile supports authentication operations, a separate connection pool is used for authentication operations. For example, if a database profile has one database instance and the number of connections is set to 1, two connections may be opened—one for authentication and one for other LDAP operations.

To illustrate the difference between the configured and actual number of connections, suppose that you have performed product setup without configuring disjoint domains. In this case, nine connections are opened by default:

  • One each, for a total of three, for the configuration data.

  • One each, for a total of four, for policy data

  • One each, for a total of two, for a database profile with one database instance and one configured connection.

As another example, suppose that you configure two database profiles, each with one database instance and an Initial Connections setting of three, and a Maximum Connections setting of five. All database instances apply to the same directory, and configuration and user data are stored in the same directory. Authentication operations are supported. In this example, the minimum connections opened to the directory is 19, as follows:

  • One each, for a total of three, for configuration data.

  • One each, for a total of four, for policy data

  • Three each, for a total of twelve, applies to the two database profiles.

    Each database profile will have six connections, since there will be two connection pools with three connections each. There will be one pool for authentication requests and another for other operations.

In this scenario, if you set the maximum number of connections to 27, the number of connections to the directory will range from 19 to 27. Configuring the Connection Pool

The following procedure explains how to configure the number of LDAP connections.

To increase the connection pool size for user data

  1. Navigate to Identity System Console, System Configuration, Directory Profiles.

  2. Click the name of a user data directory server instance in the Configure LDAP Directory Server Profiles list on the Configure Profiles page.

  3. Click the name of a directory server instance in the Database Instances list of the Modify Directory Server Profiles page.

  4. On the Modify Database Instance page, modify the two parameters below:

    • Maximum Connections: Increases the number of available connections in the pool. The default value is 1. No upper limit is enforced; you can experiment with this setting to find a suitable value.

    • Initial Connections: Specifies how many connections are opened at database initialization. The default value is 1. There is no upper limit.

2.1.3 Storing Workflow Tickets in the Directory

As described in the Oracle Access Manager Identity and Common Administration Guide, by default each workflow step generates a ticket and Oracle Access Manager writes the ticket to the directory.

One way to avoid unnecessary directory write operations is to minimize the number of steps in a workflow.

Another way to avoid unnecessary directory write operations is to change Oracle Access Manager default behavior of creating tickets for every step in a workflow.

Tickets are of little value when:

  • The information in a step has little value for the next step.

  • A participant triggers the workflow but there are no participants for other steps.

Workflow Example

Suppose you create a workflow consisting of the following steps:

  1. Initiate: The user initiates a self-registration.

  2. External action: The request is passed to an external process.

  3. Enable: The workflow is enabled.

If no one participates in steps 2 and 3, the workflow may not require a ticket. Writing Workflow Tickets to the Directory

The WFInstanceNotRequired flag determines whether every workflow step generates a ticket. This flag is set to false by default, which means all workflow instances are written to the directory. When set to true, workflow instances are only written to the directory server when:

  • A user action is required.

  • Any errors are encountered (for example, the commit action fails).

  • Any subflows are triggered.

Setting the WFInstanceNotRequired flag to true reduces the directory size and speeds up the workflow process. The disadvantage of setting this flag to true is that, because the instances are not being stored, you will not able to see all of the workflows that were executed from the Oracle Access Manager Workflow Monitor.

To avoid create tickets for every workflow step

  1. Set the WFInstanceNotRequired flag to true in the following file:


  2. Restart the Identity Server.

2.1.4 Indexing Attributes in the Directory

Indexing improves search performance in the directory, although at the cost of slower database modification and creation operations and disk space. Oracle Access Manager automatically indexes key attributes when you run the setup program. The index files are specific to your directory server type, and are stored in:


where IdentityServer_install_dir is the directory where the Identity Server is installed.

Index types include the following:

  • An equality index improves searches for directory entries that contain a specific attribute value.

  • A presence index improves searches for directory entries that contain a specific attribute.

  • A substring index improves searches for entries that contain specific text strings.

You can enhance performance if you index attributes that are read during various operations. These include:

  • Attributes used in searches that are triggered indirectly by user interaction.

  • Attributes used in searches that are explicitly invoked by users.

  • Attributes used in mapping filters for authentication schemes.

  • Attributes in filters for dynamic member definitions in Group Manager.

Your directory documentation describes how to index attributes.

Oracle Access Manager provides an index file fragment showing how Oracle Access Manager-specific attributes can be indexed for each supported directory server. For example, the Oracle Access Manager attributes that can be indexed to improve performance in a directory managed by Sun (formerly iPlanet) directory server are listed in the file:


An example of an index entry in this file is:

index obclass pres,eq,sub

This means that the attribute obclass can be indexed for presence (pres), equality (eq), or substring (sub) .


The iPlanet5_oblix_index_add.ldif file needs to be loaded to the directory server using ldapmodify. Limitations of Indexing

You should carefully weigh the benefits of indexing directory attributes for search operations against the performance hit incurred when these attributes are modified. When an attribute value is modified, indexes for that attribute may need to be rebuilt by the directory server. However, this is accomplished varies by directory server.

You should read the manufacturer's guidelines for indexing. Avoid over-indexing attributes. Indexing and User Deactivation

After you deactivate a significant number of users, Oracle Access Manager performance can start to degrade. If you experience this problem but want to maintain all deactivated users in the directory, use an equality index for the following attributes:

  • ObIndirectManager

  • ObUniqueMemberstr

An equality index allows you to search efficiently for entries containing a specific attribute value. Indexing and Workflows

If it takes a long time to delete a workflow, index any attributes that the system checks during a delete operation. Performance issues with the delete workflow function usually result from attributes that need to be indexed.

Index the following attributes using the types of equality, presence, and substring:

  • ObWorkflowID

  • ObContainerID

  • ObWFStepID

  • ObWFTargetID

  • ObIsWorkflowProvisioned

  • ObLocationDN

  • OblixGID

  • Manager

  • Secretary

An equality index type improves searches for directory entries that contain a specific attribute value. A presence index type improves searches for entries that contain a specific attribute. A substring index type improves searches for entries that contain specific strings.

For example, if you search for an attribute with a substring index type as follows:


The search would match common names containing these strings:

John Lane Jane Tulane

If you conducted this search:

telephonenumber= *123*

The search would return all entries with telephone numbers that contain 123. Indexing and Groups

The following attributes are used for group expansion and could be indexed to improve performance:

  • Any attribute configured with the obSDynamicMember semantic type

  • The obGroupExpandedDynamic attribute of the oblixAdvancedGroup object class

  • All user attributes used in the dynamic filters of the groups to be expanded. Indexing and Search Constraints

You can limit the performance impact of searches by forcing users to use a minimum number of characters for a search. This is controlled through the searchStringMinimumLength parameter. The default value for this parameter is 0.

To set a minimum number of search characters

  1. Locate seachStringMinimumLength in:

    IdentityServer_install_dir/identity/oblix/apps/common/bin/ oblixappparams.xml

  2. Set its value to the minimum number of characters for a search.

    For instance, if you set it to 6, users could not search for "Smith" because it has only 5 characters. The constraint only applies to the longest search string supplied by the user. For example, if the search is on both surname and job title, and the user enters "manager" for job title, the longest string ("manager") has 7 characters, the search is allowed. A value of 0 turns off checking.

The searchStringMinimumLength constraint is enforced for searches that are conducted using the Oracle Access Manager user interface and for clients using other interfaces to Oracle Access Manager (for example, Identity XML clients).

To enforce a per-attribute minimum number of characters

  1. Set the searchStringMinimumLength to 0 in the catalog.

  2. In the JavaScript code, find the function validateSearchAndSubmit() in the file misc.js.

  3. Modify the JavaScript code to handle the per-attribute checking you require.


This technique does not enforce the constraint on users of Identity XML clients.

As with other parameters, you can set searchStringMinimumLength to one value in the global oblixappparams.xml catalog, and to a different value in one or more of the application-specific catalogs. For example, to override the global value and set searchStringMinimumLength to a different value for User Manager, specify the parameter and its value for User Manager only in:

IdentityServer_install_dir/identity/oblix/apps/userservcenter/bin/ userservcenterparams.xml

2.1.5 Changing the Number of Access Server-to-Directory Server Connections

By default, each Access Server opens only one connection to a primary directory server and one connection to a failover directory server (if failover is configured). This may not be optimal for systems with heavy loads.

To configure additional Access Server-to-directory server connections for Oracle Access Manager configuration and policy data, use the command line tool configureAAAServer. The Oracle Access Manager Access Administration Guide provides information on this tool. In environments with very high loads (perhaps 1,000 hits/second on the Access Server), creating twenty connections has significantly improved performance.


If your directory is running on a low-powered system, the directory itself may be the limiting factor. In this case, increasing the number of connections may have little benefit. If the machine running the directory is the problem, increase the number of directory server instances and configure load balancing among them.

2.1.6 Deleting and Archiving Workflows

To prevent the Oblix tree from getting too large, periodically delete or archive workflows. Deleting a workflow instance removes the directory entries associated with that instance. Archiving a workflow instance keeps a record of the instance in an LDIF file and deletes the instance from the directory.

The frequency for archiving or deleting depends on how frequently your workflows are used.

Archived workflows are stored in LDIF format. The default archive file is:


Multiple archive operations add information to this file. You can change the archive file by changing entries in the following files:

  • User Manager


  • Group Manager


  • Org Manager


The entry to change is similar to the following:

<NameValPair ParamName="archiveFileName" Value="wfinstance.ldif"/>

To delete or archive a workflow

  1. In User, Group, or Organization Manager, click Requests.

  2. Click Monitor Requests.

    For subflows, if the first step has not been processed, the Date Processed field will be empty.

  3. In the Search fields, select your search criteria

  4. Click Go.

    The results appear below the search fields.

  5. Click individual check boxes or the Select All button.

  6. Click Next or Previous as necessary to see other results.

  7. Click the Delete or the Archive button.

2.1.7 Setting Read and Write Permissions for Administrators

By default, administrators can view all attributes in the directory so that they can perform initial setup of Oracle Access Manager. Because end users only have read permissions for specific attributes, there is a difference in performance for an administrator and an end user.

The parameter BypassAccessControlForDirAdmin controls whether the Master Identity Administrator or a delegated administrator is permitted to view all attributes in the directory. By default, the value of the parameter BypassAccessControlForDirAdmin is set to true. You can set the BypassAccessControlForDirAdmin parameter to false in the following file:


If the BypassAccessControlForDirAdmin flag is set to false, performance is the same for non-administrative and administrative users. This is because attribute read and write permissions are applied to the administrative users.

The following is an example of the parameter entry:

  <NameValPair ParamName="BypassAccessControlForDirAdmin" Value="true">

2.1.8 Configuring the Searchbase

Searchbase configuration can affect Oracle Access Manager performance. Guidelines for searchbase configuration include:

  • Set the searchbase for the user object class at a point in the people branch where all users can be found, for example, the root.

  • Minimize the number of search bases that you configure per user, group, or organization object class.

  • It is more efficient to configure attribute access controls than it is to limit user access by setting multiple search bases.

  • Use the default searchbase filter objectclass=* whenever possible.

  • Instead of defining searchbase filters, configure read and write permissions for attributes.

  • Configure workflow rules and roles to control the user's ability to view and modify attribute values. Setting a Searchbase Filter

When configuring a searchbase, if you add a filter and enter a filter other than the default (objectclass=*), the Resource Filter Search scope takes effect. The Resource Filter Search scope has no effect unless you define a filter.

The default searchbase filter (objectclass=*) instructs Oracle Access Manager to apply the user's search criteria to the entire section of the directory tree that has been selected as the searchbase. If you specify other criteria, for example, (telephone=408*), Oracle Access Manager retrieves all users who satisfy that criteria, then applies your search criteria to the subset specified by the filter instead of to the entire tree.

This can degrade performance, especially if the filter retrieves a large number of entries. For example, if you specify (objectclass=wwmOrgPerson) in the filter, Oracle Access Manager may recover all users (assuming all users satisfy this filter) under the specified tree before applying your search criteria. This can seriously degrade performance. You do not have to specify (objectclass=wwmOrgPerson) because the searchbase is already set for that object class. In general, setting read and write privileges for attributes is a better way of controlling user access than setting a searchbase filter. To optimize directory performance, avoid defining complex filters for the searchbase. In the case of searchbases for a tab, only objects of the class which that tab applies to are searched. There is no need to mention (objectclass=*) explicitly.

If you must enter a filter, you can limit the performance impact by setting the resourceSearchFilter scope parameter to 1.

2.1.9 Applying Search Constraints

The larger the number of entries that a search actually or potentially returns, the longer the search takes. For an interactive application such as Oracle Access Manager, large result sets may be unmanageable for the end user.

Your directory may allow you to limit the time that the directory server spends on a search, the size of the result, or both.

2.1.10 Increasing Connections to the Directory in the Identity System

The LDAP Database Instance Maximum Connections is the maximum number of connections allowed from the Identity Server to the directory servers. This value defaults to 1, but you may see a performance improvement by setting this value to more than 1. (With a SQL profile, the default is 5.)

There is no optimal value for the maximum connections. There are variables to consider such as directory configuration and hardware. You may want to consider setting the maximum directory connections no higher than the number of threads set for a Identity Server. For example, if the Identity Server is configured with only 20 threads, there is no benefit in having more than 20 connections because no Identity worker threads can take advantage of the additional connections.

You may want to increase the maximum connections by increments of 5, and monitor your system performance. If performance is worse, decrease the number of connections. The Initial Connections and the Maximum Connections settings work together. When an Identity Server starts, it opens the number of connections to the directory as specified in the Directory Profile Initial Connections. Those connections are then pooled and used by the Identity Server.


Additional connections can introduce overhead that in turn can hurt performance. For example, if you restart the directory server, the Identity Server has to reconnect the configured number of connections.

2.1.11 Changing Directory Content

This section describes modifications that can be made to the directory content to affect Oracle Access Manager operation. For a discussion of the tools needed to make these changes, see . Ordering the Columns in a Search Results List

A search of the Policy Manager for policy domain names or policy names returns a default set of columns in a default order. You can display different columns or change the order of columns. While this does not affect performance in terms of response times, it may improve your satisfaction with the results returned from a search.

To modify results for a policy or policy domain names search

  1. Locate the DN, for example:

    obname=SDSearchColumnList, obapp=WRSC, o=Oblix, o=Company, c=US2
  2. Under this DN, find the current column list.

    The column list consists of the values for obsearchresultcolumns.

    Possible values for a search of policy names are:

    • WRORname: Policy Name

    • AuthentPolicyName: Authentication Rule Name

    • AuthorPolicyName: Authorization Rule Name

    • AdminPolicyName: Auditing Rule Name

    • URLPrefix: URL for the domain controlled by the policy

    Possible values for a search of policy domain names are:

    • SDName: Policy Domain Name

    • AuthentPolicyName: Authentication Rule Name

    • AuthorPolicyName: Authorization Rule Name

    • AdminPolicyName: Auditing Rule Name

    • AbsPathPattern: Path to the controlled domain

For example, the following is an LDIF extract that shows the policy name, authentication rule name, authorization rule name, and URL for the domain controlled by the policy:

dn: obname=SDSearchColumnList, obapp=WRSC, o=Oblix, o=Company, c=US
objectclass: top
objectclass: OblixWRSSearchResultColumns
obname: SDSearchColumnList
obSearchResultColumns: WRORName
obSearchResultColumns: AuthentPolicyName
obSearchResultColumns: AuthorPolicyName
obSearchResultColumns: URLPrefix

To change the order or content of the displayed search results, modify this information and store it back to the directory. Changing the Bind DN

Using Directory Manager as the bind DN bypasses search limits such as look through limit, size limit, and time limit. Large searches can tie up the directory server and increase the amount of processing that is required by the Identity Server.

You can create another user to use as a bind DN.


This procedure illustrates the technique for Sun (formerly Netscape and iPlanet) directories. Consult your directory server's administration manual for instructions on how to create a directory user with the appropriate permissions.

Create your new user, for example orcladmin. Use the LDAP directory to give the user permissions to act as an administrator for Oracle Access Manager. For the searchbase, configuration base, and all branches underneath them, this user needs the following permissions:

  • Read

  • Write

  • Add

  • Delete

  • Search

  • Compare

  • Selfwrite

To change bind DN permissions

  1. From the Sun LDAP Server Admin Console, navigate to the directory server instance and open it.

  2. Choose the Directory tab, then locate and right-click the branch for which you want to set permissions.

    For example:

    for o=Company, c=US, you would find the Company node and right-click to get a menu.

  3. Choose Set Access Permissions in the menu.

  4. Add a new access permission, or edit the one already in place.

    There should be two lines when you are done. The first is a default deny for everyone, the second is the allow statement.

  5. Choose Allow, then search users and groups to find the new administrative user.

  6. Set the rights for this user.

If you make this change after installing Oracle Access Manager, change the bind DN for the Identity Server to match the value you created in the directory.

2.1.12 Adjusting Cache Settings

Caching avoids the latency of unnecessary lookups or calculations. If they keep the results of recent requests close to the consumer, producers can respond quickly by returning cached results rather than recalculating them. The cost of a cache is usually extra RAM or disk space.

A directory that manages large entries will likely hit a maximum cache size limit first, while a directory of small entries might hit the maximum number of entries limit first. If you only care about one of these two criteria, set the other to an unrealistically large number, or match their limits by setting the maximum cache size first, then dividing that number by the size of each entry to get the number you should use for maximum entries in cache.

2.1.13 Deleting ObSyncRecord Entries from the Directory---assess for other changes

Every time a change is made to a user entry in Oracle Access Manager, a directory entry called ObSyncRecord is created. This directory entry enables the user cache for different Oracle Access Manager Servers to stay in sync. If many updates are made to user entries over a short time interval, the number of ObSyncRecord entries that are written can cause a directory performance issue.

You may want to delete ObSyncRecord entries at a regular interval. If you do this, you may want to check each entry before deleting it to ensure that the entry has been in the directory for a time period that is greater than the cache-flush interval.

2.2 LDAP Tools

Directory applications use Lightweight Directory Access Protocol (LDAP) as a standard tool to create, modify, and report data stored in the directory. Tools are available to allow easy manipulation of this data. This section introduces these tools. More detail is available from the manufacturer of your server application.

2.2.1 Viewing Directory Content in LDIF Files

The structure of a directory, and the data contained within it, is represented by the content of an LDAP Data Interchange Format (LDIF) file. The file can be output, the formatted result of a request made to the directory by an LDAP reporting tool, such as LDAPSEARCH. It can also be input, data that is intended for insertion to the directory, either as entirely new data, or as an update to existing data, using an updating tool such as LDAPMODIFY.

The following is an example, part of an LDIF file taken from a Oracle Access Manager Demo Directory:

dn: cn=John Kramer, ou=Sales, o=Company, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: companyOrgPerson
cn: John Kramer
sn: Kramer
telephonenumber: 415-555-5269
facsimiletelephonenumber: 415-333-1005
title: Account Manager
departmentnumber: 1204
employeetype: Fulltime
employeenumber: 521-321-4560
givenname: John
Reporting Directory Content with LDAPSEARCH

LDAPSEARCH is one possible tool that can be used to report directory content. There are others, which use a different syntax, but the concepts are the same.

LDAPSEARCH can be used in either a command line or interactive mode. The command line approach is preferable, as it allows users to provide the text of the report request by means of a input file. It is easy to verify the content of this file before making the request. You can correct errors by changing a few characters in the file rather than retyping the full request, which would be necessary in the interactive mode. LDAPSEARCH Command-Line Format

The command-line format for LDAPSEARCH is:

ldapsearch params filter attr_list


Each of the three categories shown between <> is optional; if all are omitted, LDAPSEARCH drops into interactive mode, which is not discussed here.

The categories are as follows:

  • <params>: Parameters tell LDAPSEARCH how to operate. One of them, -f , is used to specify a filter file. If instead the search filter is provided on the command line, all parameters must be stated before the filter is stated.

  • <filter>: The filter instructs LDAPSEARCH to provide a subset of the data that would otherwise be provided. For example, a filter could require that only names beginning with N be reported. A filter provided on the command line must be enclosed in quotes.

  • <attr_list>: The attributelist, if included on the command line, overrides the default attribute listing. The default list shows all attributes belonging to the directory entry, except operational attributes. If you wish to see only some of these attributes listed, provide their names in the command line, following the filter, and separated by spaces. If you want to see operational attributes, provide their names in the command line. If you follow the operational attributes with a * you get the default list of attributes as well. LDAPSEARCH Command-Line Parameters

Parameters are always provided in the form:

-p pdata

where p is the parameter, preceded by a dash, and pdata is the information (data) required for the parameter, if any. If the data contains one or more spaces, it must be enclosed in double quotes:

-p "pdata with spaces"

Following is a list of commonly used parameters. See the reference document for your version of LDAPSEARCH, or use the parameter /? to see them listed:

  • -A: Retrieve the attribute names only, not the attribute values.

  • -b: Searchbase, the starting point for the search. The value specified here must be a distinguished name that is in the directory. Data provided for this parameter MUST be in double quotation marks. For example:

    -b "cn=Barbara Jensen, ou=Development,"

  • -D: Distinguished name of the server administrator, or other user authorized to search for entries. This parameter is optional if anonymous access is supported by your server. For example:

    -D "uid=j.smith,"

  • -f: Specifies the file containing the search filters to be used in the search. For example:

    -f filterfile

  • -h: Host name or IP address of the machine on which the directory server is installed. This entry is optional; if no host name is provided, LDAPSEARCH uses the local host. For example:-h

  • -H: This generates a list of all possible LDAPSEARCH parameters.

  • -p: Port number that the directory server listens at. For example:

    -p 1049

  • -s: Scope of the search. The data provided for the scope must be one of the following:

    • base: Search only the entry specified in the -b option.

    • one: Search only the immediate children of the entry specified in the -b parameter; do not search the actual entry specified in the -b parameter.

    • sub: Search the entry specified in the -b parameter, and all of its descendants. That is, perform a subtree search starting at the point identified in the -b parameter. This is the default, if the -s parameter is not used.

    • -S: Designates the attributes to use as sort criteria, controlling the order in which the results are displayed. You can use multiple -S arguments if you want to sort on multiple criteria. The default behavior is not to sort the returned entries. In the following example, the search results are sorted first by surname and then, within surname, by first name:-S sn -S firstname

    • -w: Password associated with the distinguished name that is specified in the -D option. If you do not specify this parameter, anonymous access is used. For example:-w password

    • -x: Specifies that the search results are sorted on the server rather than on the client. This is useful if you want to sort according to a matching rule, as with an international search. In general, it is faster to sort on the server than on the client.

    • -z: Specifies the maximum number of entries to return in response to a search request. For example:-z 1000 LDAPSEARCH Examples

To get the surname (sn), common name (cn), and given name for every employee named John in the Sales organization, from the directory server listening at port 392, entirely from the command line, you could provide the following information:

ldapsearch -p 392 -b "ou=sales, o=company, c=US" -s sub "givenname=John" sn cn givenname

Results could be something like:

dn: cn=John Jackson, ou=Sales, o=Company, c=US 
sn: Jackson 
cn: John Jackson 
givenname: John 
dn: cn=John Kramer, ou=Sales, o=Company, c=US 
sn: Kramer 
cn: John Kramer 
givenname: John

You can get the same results by using a filter file. For example, a file called namejohn containing the filter:


can be used, with the following command line:

ldapsearch -p 392 -b "ou=sales, o=company, c=US" -s sub -f namejohn sn cn givenname

2.2.2 Changing Directory Content with LDAPMODIFY

The LDAPMODIFY tool changes or adds directory content. There are other tools, but the concepts are similar. LDAPMODIFY opens a connection to the specified server, using the distinguished name and password you supply, and modifies the entries based on LDIF update statements contained in a specified file. LDAPMODIFY can also be run in interactive mode, a method that is not discussed here.

If schema checking is active when you use LDAPMODIFY, the server performs schema checking for the entire entry before applying it to the directory. If the directory server detects an attribute or object class in the entry that is not known to the schema, then the entire modify operation fails. Also, if a value for a required attribute is not present, the modify operation fails. Failure occurs even if the value for the problem object class or attribute is not being modified.


Keep schema checking turned on at all times to avoid accidently adding data to the directory that could be unusable or cause schema violations when schema checking is turned back on. Schema checking is controlled at the directory administration server console and is generally on by default. LDAPMODIFY Command-Line Format

The command line format for LDAPMODIFY is:

  • ldapmodify <params>


The params category is optional; if it is omitted, LDAPMODIFY drops into interactive mode, which is not discussed here.

<params> These parameters tell LDAPMODIFY how to operate. One of them, -f , can be used to specify a file describing modifications to be made to the directory. LDAPMODIFY Command-Line Parameters

Parameters are always provided in the form:

-p pdata

where p is the parameter, preceded by a dash and followed by a space, and pdata is the information required for the parameter, if any. If the data contains one or more spaces, it must be completely enclosed in double quotes:

-p "pdata with spaces"

Following is a partial list of commonly used parameters. Use the parameter /? to see all of them.

  • -a: Allows you to add LDIF entries to the directory without requiring the changetype:add LDIF update statement, which is necessary in the interactive mode. This provides a simplified method of adding entries to the directory; in particular, this allows you to directly add a file created by LDAPSEARCH and modified to make changes.

  • -c: Forces the utility to run in continuous operation mode. Errors are reported, but the utility continues with modifications. Default is to quit after reporting an error.

  • -D: Distinguished name of the server administrator or other user authorized to change directory entries. This parameter is optional if anonymous access is supported by your server. For example:-D "uid=j.smith,"

  • -f: Provides the name of the file containing the LDIF update statements used to define the directory modifications. For example:-f changestomake.txt

  • -h: Hostname or IP address of the machine on which the directory server is installed. This entry is optional; if no hostname is provided, LDAPSEARCH uses the localhost. For example:-h mozilla

  • -H: Lists all possible LDAPMODIFY parameters.

  • -p: Port number that the directory server uses. For example:-p 1049

  • -w: Password associated with the distinguished name that is specified in the -D option. If you do not specify this parameter, anonymous access is used. For example: -w password LDAPMODIFY Examples

Suppose you want to change the stored given name of John Kramer, as reported under the discussion of LDAPSEARCH. The data reported back was:

dn: cn=John Kramer, ou=Sales, o=Company, c=US 
sn: Kramer 
cn: John Kramer 
givenname: John

This output can be used to derive an input file, ToHarvey, whose content might be:

dn: cn=John Kramer, ou=Sales, o=Company, c=US 
givenname: Harvey

The command line would then be:

ldapmodify - p 392 -f ToHarvey

If you were to now search the directory with the command line:

ldapsearch -p 392 -b "ou=sales, o=company, c=US" -s sub "givenname=Harvey" sn cn givenname

The response would be:

dn: cn=John Kramer, ou=Sales, o=Company, c=US 
sn: Kramer 
cn: John Kramer 
givenname: Harvey

2.3 Access Server Performance Tuning

This section describes ways to tune the performance of the Access Server, including:

2.3.1 Configuring Password Validation by the Access Server

By default, when Oracle Access Manager validates a user password as part of the validate_password plug-in, it passes the request to the user directory server. The directory server validates the password and returns the result to Oracle Access Manager. This operation is slow. In an environment with many authentications, it degrades Access Server performance.

You can control whether to use the Access Server or the directory server for password validation on a scheme-by-scheme basis.

Process overview: When using Access Server password validation

  1. The first time a user's password is validated, the Access Server goes to the directory server for validation.

    If the password is valid, the Access Server caches an MD5 hash of the password. The Access Server never caches a clear text password.

  2. The next time the user's password needs to be validated, the Access Server creates an MD5 hash of the supplied password and compares it to the hash of the cached password.

    • If the two hashes match, the user's password is considered valid.

    • If the two hashes don't match, the Access Server validates the password against the directory. If the directory validates the password, the Access Server hashes it and replaces the old hash in the cache. The ObCredValidationByAS Parameter

To configure an authentication scheme so that the Access Server validates passwords, add the parameter ObCredValidationByAS with a value of true to the validate_password plug-in parameter list. To control the timeout of the cached password on a scheme-by-scheme basis, use the Time To Live parameter. The default value of the Time To Live parameter is 1800 seconds (30 minutes). To control the interval at which the Access Server goes to the directory for password validation, add the parameter obPwdHashTTL with a value equal to the number of seconds required.

The following is an example of the out-of-the-box validate_password plugin:

validate_password obCredentialPassword="password", obAnonUser="cn=anonymous, o=Company, c=US"

The following is an example of validate_password configured to use Access Server password validation with the default Time To Live parameter:

validate_password obCredentialPassword="password", ,obCredValidationByAS="true', obAnonUser="cn=anonymous,o=Company, c=US"

The following is an example of validate_password set to use the Access Server password validation with Time To Live set to 100 seconds:

validate_password obCredentialPassword="password", ,obCredValidationByAS="true" , obAnonUser="cn=anonymous,o=Company, c=US", obPwdHashTTL="100"

2.3.2 Changing the Number of Request Queues and Threads

The Access Server uses request queues to create a sequence of incoming requests that are processed by worker threads.

You can tune the performance of the Access Server by increasing the number of request queues from the default of 1. Multiple request queues can reduce contention between service threads and message threads. This can be particularly beneficial on multi-processor computers. See "To change the number of request queues" for details. If you change the number of request queues, you should also change the number of threads per queue as recommended in "Estimating the Required Number of Threads and Queues". About Threads and Queues

The request queue holds requests from AccessGates until they are processed. By default, there is one request queue.

The Access Server uses three types of threads:

  • Message threads

    Message threads accept new requests from AccessGates and append them to the request queue. The number of message threads is equal to the number of connections opened between the AccessGate and the Access Server.

  • Service threads

    Service threads remove requests from the queue and process them. Each request queue has a fixed number of service threads. The number of service threads is configured in the Access System Console. See the Oracle Access Manager Access Administration Guide for details. By default, there are 60 service threads per request queue. The total number of service threads in an Access Server is equal to the number of request queues times the number of service threads per queue.

  • Utility threads

    These perform housekeeping activities. There are usually between 20-40 utility threads, depending on the number of directory profiles configured for the Access Server, the number of file log writers defined, and so on. Estimating the Current Number of Threads

To estimate the total number of threads, take the totals for each type of thread, as follows:

  • Total message threads

    The netstat command enables you to determine the number of connections opened by AccessGates to the Access Server. Multiply this number by the number of message threads. For example, if there are 50 WebGates, each with 3 connections to an Access Server, there are 3 * 50 or 150 message threads.

  • Total service threads

    The number of service threads is configured in the Access System Console. See the Oracle Access Manager Access Administration Guide for details.

  • Total utility threads

    An average of 30 can be considered safe, using the guidelines in the previous paragraphs.

For example, if there are 50 WebGates, each with 3 connections to AccessGates, a value of 60 configured for the number of service threads in the Access System Console, and an estimated 30 utility threads, there are a total of 150 + 60 + 30 or 240 threads. Estimating the Required Number of Threads and Queues

Having many queues with a relatively small number of threads per queue can cause problems if the requests come primarily on one queue. It may be helpful to configure more than the minimum number of threads per queue. You can control the number of worker threads from the command line or from the Access Server configuration page.

If your Access Server handles more than 800 requests per second, you may need to change the number of request queues. A good rule of thumb:

  • Set the number of queues equal to the number-of-peak-requests-per-second/800.

  • Set the number threads per queue to 60/number-of-request-queues.

These recommendations are based on benchmark and performance tests. For example, if the peak request rate for an Access Server is expected to be 2000 requests per second, the number of queues should be 2000/800, or approximately 2. The number of threads per queue should be 60/2 = 30.

Avoid having too few or too many threads per queue. Four threads is adequate for benchmarking, but if the directory server is slow in responding you might need more. The optimal number for the total number of threads may be closer to 100 for a modest improvement in performance on a large, fast system. However, performance is not excessively sensitive to the number.

For example, an environment with 16 queues and 16 threads apiece (256 total threads) produced about 9,000 TPS during a lab test with directory access turned off. An environment with 16 queues and 4 threads apiece (64 total threads) produced about 9,400 TPS on the same configuration. For even the largest deployments, 8 queues should be enough, and 2-4 queues may be sufficient.

To change the number of request queues

  1. When starting the Access Server from the command line, type the following:

    aaa_server -i install_dir -Q n

    where n is the number of request queues. The number of queues must be an integer to a maximum of 1024.

    When using Access Server service on Windows NT or Win2K the -Q option must be specified as a startup parameter to the service. Alternatively, you can modify the following script to include this parameter:

  2. Restart the Access Server for this parameter to take effect.

2.3.3 Performance Considerations when Using ObMyGroups

There are several situations where the use of obmygroups proves to be a powerful approach for further integrating the Access System with applications to provide role-based information on the given user. For example, a given application could be modeled as the same set of URLs whose access is restricted only to the members of a few groups in LDAP. However to drive the navigation or presentation of the application, the application would need to know which groups the particular user belongs to because specific menu items or functions would be presented based on group membership. In this case, setting an action with ObMyGroups would be a seamless way to supply such information to the application, thus isolating the application from having to query LDAP directly or resolve whether the group is static, nested, or dynamic.

Using ObMyGroups as an authentication or authorization action requires you to consider the performance implication that resolving user group membership could have in the system for the LDAP directory and Access Server, and consequentially the Web server and application being accessed.

Guidelines for ObMyGroups

Following are some guidelines and considerations that apply to this feature:

When using ObMyGroups, by default, Oracle Access Manager searches for all group objects within the searchbase and then builds a user/group relationship cache in the Access Server, called the Group Query Cache.The searchbase used is the Access System searchbase. No Oracle Access Manager ACLs would apply to the query. For example, all groups the user belongs to are supplied, regardless of whether or not the user has read rights to those groups' class attribute.

The user/group relationship cache is built by checking group membership in this order:

  1. Static Groups Membership

  2. Dynamic Group Membership

  3. Nested Group Membership

The Group Query Cache expires every 10 minutes. This timeout is not currently configurable. Contrary to user entries in the Access Server cache, there is no flush mechanism for the Group Query Cache other than waiting for the cache timeout or restarting the Access Servers.


In general the user/group evaluation is an expensive operation from an Access Server perspective. Oracle strongly recommends that these always be configured with a qualifying LDAP filter. For example, enter obmygroups:ldap:///o=company,c=us??sub?(group_type=role).

Depending on the number of groups being searched, ObMyGroups processing may take a significant amount of time. It is best to specify obmygroups in an authentication rule rather than an authorization action and, if possible, have the action be a cookie so that the data is available to other applications under the same Web server without incurring an additional toll.


When ObMyGroups is used in an authorization rule, limit its use to as few resources (URLs) as practical.

Even though user/group relationship information is in the Group Query Cache, the entire cache must be evaluated for each resource protected by a policy that contains an authorization action. The entire cache must be evaluated because all groups must be checked to see if the user is in that group. So even though it's a cache lookup, it's an expensive lookup. You need to consider the Access Server performance impact of using ObMyGroups for authorization actions.


Oracle strongly recommends that a thorough performance test, with the specific use cases relevant to ObMyGroups actions, be designed and executed prior to rollout. This allows you to benchmark, tune, and understand the actual performance and response times involved in your specific environment.

2.3.4 Limiting the Number of Authorization Queries from WebGate

When you define access policies for a policy domain, the WebGate by default will query the Access Server every time a user attempts to access resources in that domain. The more broad the policy domain, the more often the Access Server is queried. For example, if you configure root (/) as the policy domain in the Policy Manager, the WebGate will contact the Access Server every time someone tries to access a resource on the entire Web site.

To minimize the number of times the WebGate queries the Access Server, you can configure the DenyOnNotProtected flag. When set to true, DenyOnNotProtected denies access to all resources to which access is not explicitly allowed by a rule or policy. This can limit the number of times the WebGate queries the Access Server, and can improve performance for large or busy policy domains. See Oracle Access Manager Access Administration Guide for details.

2.4 Tuning the Caches

You can tune three groups of Access System caches:

For additional information, see Chapter 4, "Caching and Cloning" .

2.4.1 Tuning the Policy Cache

A policy cache contains information about policy domains, excluding URLs, policy descriptions, and display names. A policy cache element contains the following:

  • Rules

  • Actions associated with rules

  • Filters, groups, and roles associated with rules

  • Policy conditions for rules

  • All policy domains

  • All policies

  • All authentication schemes

You tune the policy cache by setting the Maximum Elements in Policy Cache and Policy Cache Timeout parameters.


These parameters are also documented in the Oracle Access Manager Access Administration Guide. Calculating Maximum Elements in a Policy Cache

To estimate the requirements, calculate the total number of authorization rules in all policy domains and policies. To do this, search the Oblix directory tree using the following filter:


When determining the number of elements in a policy cache, be sure to account for future growth of the number of rules. Calculating Memory Requirements for the Policy Cache Elements

To calculate the memory requirements for the Access Server's policy cache elements, check the memory requirements of the directory used to store the policies.

This value is roughly the value you should provide on the Access Server. Calculating Policy Cache Timeout

When a policy domain, rule, or policy is created or modified, the administrator has the ability on each screen to Update Cache. When these screens are saved, this forces an immediate flush of the relevant policy cache, ensuring that the change takes effect immediately.

You can have the caches time out on a regular basis as a security precaution or to clean up if the administrator does not press the Update Cache button during a policy change. The Oracle Access Manager Access Administration Guide discusses automatic flushing of the Access System cache.

2.4.2 User Cache Tuning

The tuning parameters available for this are Maximum Elements in User Cache and User Cache Timeout. Calculating the User Cache Timeout

The user cache contains all user attributes and values used in audit and HTTP actions. You need to determine the shortest time acceptable for not changing bulk user attribute values. If the value is too large, values that are considered important from a risk-management perspective may not make their way into Oracle Access Manager until the cache is flushed. This can be a problem if the administrator forgets to update the cache after making changes. The administrator, delegated identity administrator, or user may change a user value in the directory and think it has been implemented when, in fact, there will be a delay until the value in the cache is flushed.

On the other hand, you should avoid setting the timeout or the cache size so small that data is flushed while a user is accessing a site, since this forces another trip to the directory.

To estimate a reasonable interval for updating user values, you can track average session times over a 24-hour period. The User Cache Timeout value can probably be set to this value or slightly higher than this value. Calculating Maximum Elements in the User Cache

If you know the value for User Cache Timeout, you should next measure the number of users who access resources during this time interval.

When you know the maximum number of concurrent users during the time interval, the number represents the maximum number of cache elements. This is because each element contains a user DN and their attributes and values used in the audit logs and HTTP actions. Calculating Memory Requirements for User Caches

If you know the user cache timeout and the maximum number of elements in the user cache, you can calculate hardware requirements.

To begin, calculate the requirements per cache element. An element in the user cache refers to all user attributes and their values used in all the rules. The formula for this is:

cache element size = size of DN + size of all attribute values to be cached + 50 bytes for overhead

You can now calculate total memory requirements as follows:

Max. elements in user cache memory requirements = Max. elements      x cache element size

2.4.3 Tuning the URL Prefix Cache

The URL prefix cache sets the interval for flushing a URL prefix. If a URL prefix is added to a policy domain or policy, the administrator can click the Update Cache button to force an automatic cache flush. The URL Prefix reload period is an additional safeguard that provides automatic flushing.

Choose a time interval that you feel comfortable with between automatic cache flushes. The default value is 7200 seconds, or two hours.

2.4.4 WebGate Cache Tuning

WebGate caches information on authentication and on whether or not a resource is protected. WebGate cache tuning refers to the total number of unique URLs expected over the timeout interval.

The chances of an authentication scheme changing quickly are very low. The chances of a URL prefix being changed or added are low. If an administrator adds, changes, or deletes a URL prefix, the screens contain an Update Cache button for forcing an immediate cache flush. As a result, the default value for the WebGate cache timeout is zero. This means that the cache is not automatically updated and is flushed only when the administrator clicks the Update Cache button. If you are not comfortable with the default, choose an appropriate interval before the URL is automatically flushed from the cache.

2.4.5 Sizing the Maximum Elements in Cache

WebGate can cache URLs to avoid trips to the Access Server or directory server when determining if a URL requires protection. The default value for Maximum Elements is 100,000. To estimate an appropriate value for this parameter, examine the number of URLs that the Web server is protecting and the HTTP operations associated with them.

Web browsers place an internal limit of 4096 bytes on URLs. Most URLs are smaller than 4096 bytes. You may want to determine upper limits for the cache and choose the same size or a smaller size than 4096, depending on what you believe is an average URL size.

To calculate memory requirements per cache element:

memory per cache element = URL (4096 bytes) + overhead (128 bytes) = 4224 bytes

To calculate the memory requirements for maximum cache elements:

memory required = 100,000 elements x 4224 bytes/element = 422,400,000 bytes = 422 MB of memory

Memory requirements may be smaller if the maximum number of elements is downsized according to the needs of the Web server that the WebGate is on and the average size of the URLs.

2.5 Tuning the Identity System

It is a good practice to use at least two Identity Servers running in a pooled primary configuration. Pooled primary means using multiple Identity Servers that run as primary servers, with one or more WebPass instances connecting to the primary Identity Servers.

You can use separate Identity Servers as secondary servers when using a pooled primary approach. If you have only two servers, a pooled primary configuration is recommended over using one primary and one secondary server. When running a pooled primary configuration, it is best to use identical but separate hardware for the Identity Servers.

Advantages of pooled primary mode

Disadvantages of pooled primary mode


Identity Server configuration and stylesheet files must be identical on all servers. This applies to all configurations that use multiple Identity Servers. You should configure all Identity Servers from a file system level, that is, ensure that all directory and file system structures are identical.

2.6 Tuning the Group Manager

The Group Manager is a Oracle Access Manager application. The Group Manager has unique performance tuning requirements. In particular, group size can adversely affect performance. For instance, if you have groups of more than 100,000 users, operations involving these groups may be slow. Similarly, nested groups can result in slow performance during evaluation due to the large number of members in the nested groups. Where possible, use dynamic groups instead of nested groups.

In addition, three Group Manager pages can be tuned to optimize performance:

2.6.1 Tuning the My Groups Page

You can tune the performance of the My Groups page as follows.

To tune the My Groups page

  1. In the Identity System Console, navigate to Group Manager Configuration, Group Manager Options.

    On this screen are several Boolean flags that you can set by clicking Modify. The Oracle Access Manager Identity and Common Administration Guide describes these settings. As an example of how these flags might influence the performance of your system, consider the setting labeled Show nested groups. Showing nested groups can be a time-consuming operation, depending on the complexity of the group hierarchy. Setting this option to false limits group display to a simpler format, but can significantly improve the performance of the page.

    The types of attributes in step 2 are used in the My Groups profile.

  2. To improve directory performance, index the following:

    • Attributes configured with the ObSDynamicMember semantic type

    • Attributes configured as the ObSStaticMember semantic type

    • All user attributes used in group dynamic filters

  3. Group Manager can use an optional filter--the extra group filter--to further qualify results shown in the My Groups profile.

    The filter can be used to further qualify results under any searchbase, but would most likely be used in a FAT tree scenario where all entries are located under one container. The parameters that control the use of this filter are extra_group_filter and use_extra_group _filter_mygroups, found in the groupdbparams.xml catalog. The extra filter can be any LDAP filter and, in addition, may contain an Oblix rule substitution ($ $). When using a rule substitution, the substituted value comes from the user entry. This provides a means to link the values of attributes in a user entry with those in group entries. For example, a filter such as ou=$ou$ would specify, that in order for a group entry to qualify, the ou of the group must be the same as that for the user.

  4. The default stylesheet for the My Groups page uses DHTML and layers to render the groups in a browseable tree format. If the My Groups page has to show many groups, the browser may take a long time to render the page. You can replace the default stylesheet, gsc_myprofile.xsl, with gsc_myprofile_simple.xsl. This version of the stylesheet has a simpler, non-browseable interface and does not use DHTML and layers as much. Both stylesheets are located in the directories:

    IdentityServer_install_dir/identity/oblix/lang/en-us/style0/ (stylesheet template)IdentityServer_install_dir/identity/oblix/shared/ (wrapper stylesheet)

For details about stylesheets and styles, see the Oracle Access Manager Customization Guide.

To use gsc_myprofile_simple.xsl

  1. Change the XML registry settings in the registry file:


  2. In this file, change the following line:

    <ObStyleSheet name="gsc_myprofile.xsl"/>


    <ObStyleSheet name="gsc_myprofile_simple.xsl"/>
  3. Then restart the Identity Server and Web server.

2.6.2 Tuning the View Members Page

You can tune the performance of the View Members page in the following ways:

  • You can control the behavior of the View Members page using three Identity System Console options.

    These options can be turned on and off in the System Configuration, Group Manager Configuration, Group Manager Options page. See the Oracle Access Manager Identity and Common Administration Guide for information on these flags.

  • You can constrain the search that can be done in the View Members page. Locate the groupMemberSearchStringMinimumLength parameter in the catalog:


    This parameter controls the minimum number of characters that the user must type to be able to search for members of a group. Other than being restricted to group membership searches, its usage is identical to that of the searchStringMinimumLength parameter (see for details).

  • You can index any user attributes used in group dynamic filters.

2.6.3 Tuning the Group Expansion Page

The following attributes are used in group expansion and should be indexed to improve performance:

  • Any attributes configured with the ObSDynamicMember semantic type.

  • The obgroupexpandeddynamic attribute of the oblixadvancedgroup objectclass.

  • All user attributes used in the dynamic filters of the groups to be expanded.

  • As discussed under see you should use the Set Searchbase feature to localize access to sub-domains appropriately. This may also improve the performance of the Group Expansion page.

The performance of the Group Expansion page may be improved by using the extra group filter feature, discussed under see .

2.7 Tuning Workflows

Workflow performance can be tuned in several ways:

Workflows are also mentioned in the sections on directory tuning and indexing. See "Storing Workflow Tickets in the Directory" and "Indexing and Workflows" for details.

2.7.1 Tuning workflowdbparams.xml

The workflowdbparams.xml file resides in the following location:


The following parameters can be tuned to assist with workflow performance. You must restart the Identity Server for changes to these parameters to take effect:

  • WfDefCacheMaxNoOfElements—This parameter sets the size of the workflow definition cache. Set the value of this parameter to be higher than the number of defined workflows.

  • WfDefMaxNumStepDefFiltersPerSearch—This parameter controls how many searches the Identity System performs on instance data. If users are participants in a large number of workflow steps, increasing the value of this parameter can reduce the number of times the directory is searched. To experiment with this parameter, increase its value in increments of 20. A higher number reduces searches to the directory, but increases the LDAP filter length. You can monitor the directory CPU utilization to determine an optimum value.

2.7.2 Configuring Workflow Search Parameters

The following guidelines will help you tune workflow search performance:

  • Check the number of search results that are returned per page. The default is 20. A higher number of results per page may cause slow performance.

  • If workflow participants are specified as a filter, performance will be slower. See if participants can be specified using a static group.

2.8 Tuning Your Network

The performance of the overall network, or network latency, is a major factor in the performance of the system. A reduction in network latency will be reflected in the performance of Oracle Access Manager.

It is not necessary, and not even desirable, for you to deploy load balancers between Oracle Access Manager components, even if you use load balancers for other application deployments. You should avoid placing load balancers between an Access or Identity Server and any of the following components:

Oracle Access Manager uses the LDAP protocol to perform update operations, and it provides keep alive, failover, and failback functionality to handle LDAP and network outages, replication, and related activities. The built-in features of Oracle Access Manager are often the same or better than similar features provided by a load balancer.

In some cases, you can negatively affect the performance of Oracle Access Manager by placing a load balancer between its components. For example, a load balancer may terminate a connection that it interprets as idle without triggering a response that Oracle Access Manager can detect and adjust to. This can cause outages.

The following are guidelines for tuning your network:

2.8.1 Be Sure Your Machines Are Working Properly

If you experience performance issues, you may want to check system CPU usage. For example, if a domain controller is not working well, performance will suffer.

2.9 Resource-Intensive Operations

Resource-intensive operations include login forms, password management, and plug-ins.

The following are issues you should examine to optimize performance.

2.9.1 Login Forms

Login forms increase the overall load on Web servers. This may mean that you need more Web servers, depending on the size of the server and the form content. Dynamic contents and graphics adversely affect performance. An extremely high number of logins can cause network latency.

2.9.2 Password Management

Password management causes many directory write operations. When you implement password management, be aware that there are performance implications if you expect it to be used frequently.

2.9.3 Plug-Ins

Oracle Access Manager plug-ins and .exe files can affect performance. When you develop customizations for Oracle Access Manager, be aware of the impact of these customizations. To minimize performance impact:

  • When creating an action for the Identity Event API, because an action incurs overhead, you should identify all the possible events to attach the action to and choose the least frequently used one that yields the desired result.

  • Evaluate the sequence in which actions are executed.

    For example, suppose that you develop a .exe file to send an email message through the SMTP server when a user performs a particular action. Depending on how you write this program, the Identity Server may be unable to perform further actions until it receives a reply from the SMTP server. If it is the case that the SMTP server is down, there may be a large impact on performance.

  • When comparing EXEs and LIBs, note that LIB actions execute quickly because they are binary code modules compiled from C or C++ source code. However, their perceived speed depends on the function they perform.