JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Identity Analytics System Administrator's Guide 11g Release 1
search filter icon
search icon

Document Information

Preface

1.  Understanding and Configuring the System Log

2.  Using System Logs

3.  Oracle Identity Analytics Troubleshooting

4.  Tuning GlassFish To Run Oracle Identity Analytics

Overview

Understanding Operation Requirements

Application Architecture

Hardware Resource

Process Overview

Tuning the Application Server

Deployment Settings

Disable "Auto-Deployment"

Disable "Dynamic Application Reloading"

Logger Settings

General Settings

Log Level Settings

Web Container Settings

Session Properties: Session Timeout

Disable Dynamic JSP Reloading

Thread Pool Settings

Tuning Thread Pool Settings (UNIX and Linux Only)

Tuning the Java Runtime Environment

Java Virtual Memory Settings

Managing Memory and Garbage Collections

Tuning the Garbage Collector

Tracing Garbage Collection

Other Garbage Collection Settings

Tuning the Java Heap Size

Guidelines for Java Heap Sizing

Heap Tuning Parameters

Tuning the Operating System

Server Scaling

Processors

Memory

Disk Space

Networking

Tuning the Application Server

This section describes how to tune the GlassFish application server for optimum performance.

Deployment Settings

Deployment settings can have a significant impact on performance. The recommendations that follow ensure optimum performance when deploying Oracle Identity Analytics on the application server.

Disable "Auto-Deployment"

Enabling auto-deployment can adversely affect deployment because the Reload Poll Interval setting can impact performance significantly. For a production system, disable auto-deploy to optimize performance.

Disable auto-deployment through the Admin Console by choosing Stand-Alone Instances > Server (Admin Server) on the Advanced/Applications Configuration tab.

Disable "Dynamic Application Reloading"

When dynamic reloading is enabled the application server periodically checks for changes in deployed applications and automatically reloads them if changes are found. Dynamic reloading is intended for development environments and is incompatible with session persistence. To improve performance, disable dynamic class reloading.

Disable dynamic class reloading for an application that is already deployed by opening the Admin Console and choosing Stand-Alone Instances > Server (Admin Server) on the Advanced/Applications Configuration tab.

Logger Settings

The application server writes messages and exception stack trace output to the log file in the logs directory of the instance, located here: appserver-rootdomain-name /logs. A high volume of log activity can impact server performance, particularly during benchmarking situations.

General Settings

In general, writing to the system log slows down performance slightly, as does increased disk access. Increased disk access results when log levels are increased and file rotation limits or time limits are decreased.

Also, make sure that any custom log handler does not log to a slow device like a network file system since this can adversely affect performance.

Log Level Settings

Set the log level for the application server and its subsystems by opening the Admin Console, selecting the Logger Settings page, and clicking the Log Levels tab. The page enables you to specify the default log level for the server (labeled Root), the default log level for javax.enterprise.system subsystems (labeled Server) such as the EJB® container, MDB container, Web container, Classloader, JNDI naming system, and Security, and for each individual subsystem.

Log levels vary from FINEST, which provides maximum log information, through SEVERE, which logs only events that interfere with normal program execution. The default log level is INFO. The individual subsystem log level overrides the Server setting, which in turn overrides the Root setting.

For example, the MDB container can produce log messages at a different level than the application server default. To get more debug messages, set the log level to FINE, FINER, or FINEST. For best performance under normal conditions, set the log level to WARNING. Under benchmarking conditions, it is often appropriate to set the log level to SEVERE.

It is also best to set all Oracle Identity Analytics logging levels in log4j.properties to WARN.

Web Container Settings

Set Web container properties in the Admin Console by choosing Configurations > Config-name > Web Container.

Session Properties: Session Timeout

Session timeout determines how long the application server maintains a session if a user does not explicitly invalidate the session. The default value is 30 minutes. Setting a very large value for session timeout can degrade performance by causing the server to maintain too many sessions in the session store. However, setting a very small value can cause the server to reclaim sessions too soon.

Disable Dynamic JSP Reloading

On a production system, improve Web container performance by disabling dynamic JSP reloading. To do so, edit the default-web.xml file in the config directory for each instance.

Change the servlet definition for a JSP file to look like this:

<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
<init-param>
<param-name>development</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>xpoweredBy</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>genStrAsCharArray</param-name>
<param-value>true</param-value>
</init-param>
 <load-on-startup>3</load-on-startup>
</servlet>

Thread Pool Settings

You can both monitor and tune thread pool settings through the Admin Console. To configure monitoring with the Admin Console, choose Configurations > Config-name > Monitoring. To view monitoring information with the Admin Console, choose Stand-Alone Instances > Instance-name (Monitor).

Tuning Thread Pool Settings (UNIX and Linux Only)

Configure thread pool settings through the Admin Console by choosing Configurations > Config-name > Thread Pools.

Because UNIX and Linux threads are always operating system (OS)-scheduled, as opposed to user-scheduled, UNIX and Linux users do not need to use native thread pools. Therefore, this option is not offered in a UNIX or Linux user interface. It is possible, however, to edit the OS-scheduled thread pools and add new thread pools, if needed, using the Admin Console.