Skip Headers
Oracle® Fusion Middleware Performance and Tuning Guide
11g Release 2 (11.1.2)

Part Number E28552-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

27 Oracle Adaptive Access Manager Performance Tuning

This chapter provides guidelines for tuning and sizing Oracle Adaptive Access Manager (OAAM). It covers these topics:

Note:

Before tuning Oracle Adaptive Access Manager review and implement the general tuning configurations discussed in Chapter 2, "Top Performance Areas".

27.1 About Oracle Adaptive Access Manager

Oracle Adaptive Access Manager (OAAM) provides real-time or batch risk analysis and adaptive authentication capabilities to actively prevent fraud. Out of the box integrations with Oracle Identity Manager (OIM) and Oracle Access Manager (OAM) secure web single sign-on and self-service password management flows with adaptive authentication.

For more information on Oracle Adaptive Access Manager, see Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

27.2 Performance Considerations

Effective Oracle Adaptive Access Manager performance tuning starts with a good understanding of its usage and general performance issues. Before you begin tuning Oracle Adaptive Access Manager, review this section as well as the recommendations discussed in Top Performance Areas:

Table 27-1 Oracle Adaptive Access Manager Performance Considerations

Number of users

Understanding the overall user population size; group, membership and attribute counts; data types, and configuration parameters of the LDAP and database is essential for properly tuning Oracle Adaptive Access Manager. See Performance Planning for more information on using population data to improve performance.

Daily activity usage

It is important to know how many users are active during a 24-hour period and the expected traffic. Spikes in usage may require additional tuning to avoid performance issues. See Monitoring Oracle Fusion Middleware for more information on collecting performance data.

Hardware resources and topology

Like any application deployed in demanding, real-time environments, proper server sizing and configuration is critical for acceptable Oracle Adaptive Access Manager performance. Ensuring that your hardware is sufficient to prevent bottlenecks is a key factor in performance tuning Oracle Adaptive Access Manager. See Securing Sufficient Hardware Resources for more information on optimizing hardware resources.

Protected applications

Knowing which applications Oracle Adaptive Access Manager is protecting and how that protection is modeled is an important consideration when tuning. Specifically you should understand how the applications are being protected: using WebGates (10g,11g, or 11gPS1); mod_osso; custom AccessGates; or a combination.

JVM and garbage collection

Optimal performance of Oracle Adaptive Access Manager depends on correctly tuning JVM heap sizes and garbage collection. See Configuring Garbage Collection and Specifying Heap Size Values in Tuning Java Virtual Machines (JVMs)for more information.


27.3 Monitoring Oracle Adaptive Access Manager

To identify performance bottlenecks, you should monitor real-time performance metrics for Oracle Adaptive Access Manager. The following sections describe ways to monitor Oracle Adaptive Access Manager and what you should be monitoring to ensure Oracle Adaptive Access Manager is meeting your performance requirements:

27.3.1 Enabling Dynamic Monitoring Service (DMS)

Consider enabling Dynamic Monitoring Service (DMS) performance instrumentation which can tell you the latency and throughput of functional and operational metrics. DMS can identify components that are either processing a heavier load or taking longer than usual to service requests. See Viewing DMS Metrics for more information on determining the overall time to process calls to various components

27.3.2 Using the Oracle Adaptive Access Manager Admin Console Dashboard

Oracle Adaptive Access Manager Admin Console provides a performance dashboard that shows the performance of the traffic that is entering the system. A trending graph is shown of the different types of data based on performance. For more information on accessing and using the Oracle Adaptive Access Manager Admin Console, see "OAAM Admin Console and Controls" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

Specifically you should use the dashboard to monitor performance of the following:

  • Average execution time of Checkpoints (first) and Rules (second) and their trending data.

  • Response time of APIs and their trending data

  • Statistics such as the number of logins and transactions can tell you when the system is handling larger numbers of users. This information will help you determine your overall performance strategy.

27.3.3 Monitoring Oracle Adaptive Access Manager Server Logs

Consider monitoring the Oracle Adaptive Access Manager Server logs to check for messages related to slow-running SQL statements and errors. For example, If you notice numerous messages that are related to high response times of the SQL statements, then that usually means there are issues in the database. In this case the DBA should look at the database and investigate further to narrow down the issue.

To view the server log files, you can use Oracle Enterprise Manager Fusion Middleware Control or go to the Oracle Adaptive Access Manager home directory and look at the Oracle Adaptive Access Manager Server log files to find these issues.

For more information on using Oracle Adaptive Access Manager Server logs, see "Configuring Logging Output" in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

27.3.4 Analyzing Automatic Workload Repository (AWR) Reports

To monitor the health of Oracle Adaptive Access Manager database the AWR reports can be used to pinpoint issues in the database. You can use Oracle Enterprise Manager to view these reports.

27.4 Basic Tuning Considerations

This section provides the basic tuning considerations for Oracle Adaptive Access Manager. It contains the following tuning recommendations:

27.4.1 Using Purge Scripts to Improve Performance

OAAM uses purge scripts to archive and purge different sets of transactional tables in the OAAM database. Purging releases disk space in the database for current data and deletes obsolete data. The purge process can be based on the age of the data or the type of data. By default OAAM purge scripts will archive data that will be deleted during the purge process. Targeted transaction and entity data archive and purge using the OAAM Admin Console is available in OAAM 11.1.2.

For more information, see "Setting Up Archive and Purge Procedures" in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

27.4.2 Tuning Database Parameters for OAAM

When tuning Oracle Adaptive Access Manager, you must first review the baseline tuning parameters for your database. For more information, see Section 2.6, "Tuning Database Parameters".

27.4.3 Tuning Oracle Internet Directory

To ensure that the Oracle Adaptive Access Manager is performing at the optimal level, it is important to tune the Oracle Internet Directory as described in Chapter 23, "Oracle Internet Directory Performance Tuning".

27.4.4 Tuning Applications

Oracle Adaptive Access Manager performs best when the following application parameters are set:

27.4.4.1 Tuning Java Virtual Machine Parameters

To optimize Oracle Adaptive Access Manager, See the Java Virtual Machine tuning recommendations discussed in Section 2.4, "Tuning Java Virtual Machines (JVMs)".

27.4.4.2 Tuning JDBC Connection Pool for OAAM

JDBC Datasource OAAM_ADMIN_DS is used by the Oracle Adaptive Access Manager administration server for configuration. JDBC Datasource OAAM_SERVER_DS is used by the Oracle Adaptive Access Manager administration server for customer authentication and other transactional purposes. To increase the capacity of the JDBC connection pools consider the following:

Parameter Description

OAAM_ADMIN_DS

Set the Initial Capacity to one half of the Maximum Capacity. For example, consider setting the Initial Capacity to 50 and Maximum Capacity to 100.

OAAM_SERVER_DS

Set the same value for Initial Capacity and Maximum Capacity. For example, consider setting the Initial Capacity and Maximum Capacity to 100.


For more information on using the Oracle WebLogic Administration Console to modify connection pools, see "Configure JDBC generic data sources" in the Oracle WebLogic Console online help.

27.4.4.3 Setting Logging Levels

For Oracle Adaptive Access Manager performance testing and production environments, consider using the lowest acceptable logging level whenever possible.

By default, log messages are written to the access.log file only when logging is set to NOTIFICATION:1. To maintain performance, consider keeping the default log level ERROR:1 (SEVERE) or use WARNING:1 (WARNING) to limit the amount of information written to the access.log file.

For more information on tuning the Oracle WebLogic Server log files, see the Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server.

27.5 Advanced Tuning Considerations

The following Oracle Adaptive Access Manager tuning considerations are provided as a guide. Always consult your own use case scenarios to determine if these configurations should be used in your deployment.

27.5.1 Disabling Tracker Node History Logging

If the history of the device is not required, then device history logging can be turned OFF by setting the property bharosa.trackernodehistory.enable to false using Oracle Adaptive Access Manager Admin Console.

27.5.2 Tuning Rule Logging Entry Creation

By default detailed rule logging takes place whenever a rule takes more than 2000 milliseconds (2 seconds) to execute. This is controlled through the vcrypt.tracker.rulelog.detailed.minMillis property.

27.5.3 Tuning Auto-learning Data Collection

The Auto-learning feature tracks transactions and authentications being performed by different actors based on patterns you create. This process establishes what is "normal" or average behavior for an individual or a population. By default, Auto-learning collects data for hourly, daily granularity that is not used by the out-of-the-box patterns. If there are no custom patterns that use hourly, daily granular data, then that data collection can be disabled by setting the following properties to false:

tracker.wf.createHourlyEntries
tracker.wf.createDailyEntries

Note:

When auto-learning is disabled, no pattern-based risk analysis will be performed. Consider this before you disable auto-learning as the risk analysis may be an important part of your data collection.

27.6 Specific Use Cases That Require Additional Tuning

This section describes some specific use cases that may benefit from additional tuning.

27.6.1 Oracle Access Manager Integration Tuning Parameters

The following properties and default values are used to create the Oracle Access Manager Client Object Pool. These parameters can be configured to higher values if the login volume is high.

oaam.oam.oamclient.timeout = 3600
oaam.oam.oamclient.periodForWatcher = 3600
oaam.oam.oamclient.initDelayForWatcher = 3600
oaam.oam.oamclient.minConInPool =10
oaam.uio.oam.num_of_connections = 5

27.6.2 Oracle RAC Specific Tuning Parameters

If Oracle RAC is used to host an Oracle Adaptive Access Manager database, then consider setting the following parameters to improve Oracle Adaptive Access Manager database performance:

  • Use Reverse Key Indexes for primary keys of the tables to reduce contention:

    VCRYPT_TRACKER_USERNODE_LOGS

    VCRYPT_TRACKER_NODE

    VT_SESSION_ACTION_MAP

  • Create partitioned indexes on heavily accessed tables to reduce index contention.

27.6.3 SOAP Deployments

In deployments where applications are integrated with Oracle Adaptive Access Manager using SOAP (Simple Object Access Protocol) option, the following should be considered to optimize performance:

  • Make sure there are no network issues between the SOAP client and Oracle Adaptive Access Manager Server

  • To reduce DNS resolution issues, specify the IP Address of the Oracle Adaptive Access Manager Server where SOAP services are hosted as the value of Oracle Adaptive Access Manager Host in vcrypt.tracker.soap.url property

27.6.4 Oracle Adaptive Access Manager Offline Deployment

If you are using Oracle Adaptive Access Manager offline to perform risk evaluations on historical or non-real time login/transactional data, you may need to complete some additional configurations to ensure performance is maintained. For more information on using Oracle Adaptive Access Manager Offline, see "OAAM Offline" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.