Skip Navigation Links | |
Exit Print View | |
Oracle Identity Analytics System Administrator's Guide 11g Release 1 |
1. Understanding and Configuring the System Log
3. Oracle Identity Analytics Troubleshooting
4. Tuning GlassFish To Run Oracle Identity Analytics
Understanding Operation Requirements
Tuning the Java Runtime Environment
Managing Memory and Garbage Collections
Other Garbage Collection Settings
This section describes how to tune the GlassFish application server for optimum performance.
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.
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.
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.
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.
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.
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.
Set Web container properties in the Admin Console by choosing Configurations > Config-name > Web Container.
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.
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>
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).
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.