Creating View Objects View Objects Tuning

Oracle Application Development Framework Performance Tuning 8-19 Most of the AM pool parameters can be set through Oracle JDeveloper. The configurations are saved in bc4j.xcfg, which can be manually edited if needed. Parameters can also be set at the system level by specifying these as JVM parameters -Dproperty=value. The bc4j.xcfg configuration takes precedence over the JVM configuration; this enables a generic system-level configuration to be overridden by an application-specific exception.

8.3.5.1 General AM Pool Configurations

The following guidelines can be used as a general starting point when tuning AM and AM pool behavior. Details for each parameter can be found in the Oracle Fusion Middleware Fusion Developers Guide for Oracle Application Development Framework. More specific tuning for memory or CPU usage can be found in Section 8.3.5.2, AM Pool Sizing Configurations . Table 8–7 Application Module AM Pool Tuning Configuration Recommendation Description Optimize the number of AM pools in the application. Parameters applied at the system level are applied per AM pool. If the application uses more than 1 AM pool, then system-level values for the number of AM instances must be multiplied by the number of AM pools to realize the actual limits specified on the system as a whole. For instance, if an application uses 4 separate AM pools to service the application and a system-level configuration is used to limit the max AM pool size to 100, then this can result in a maximum of 400 AM instances 4 pools 100 max pool size. If the intent is to limit the entire application to a max pool size of 100, then the system-level configuration should specify a max pool size of 25 100 max pool size 4 pools. Finer granularity for configuring each AM pool can be achieved by configuring each pool separately through JDev or directly in bc4j.xcfg. Optimize the number of database connections. By default AM instances retain their database connections even when checked back into the AM pool. There are many performance benefits to maintain this association. To maintain performance, consider configuring more AM instances than the maximum number of specified database connections. NOTE: If you have an AM pool that needs to be used as root pool, consider tuning at the specific AM pool level. For pools that are infrequently used, consider tuning pool sizes on the pool level so that top-level application parameters are not used. For more information see Setting Pool Configuration Parameters in Oracle Fusion Middleware Fusion Developers Guide for Oracle Application Development Framework. 8-20 Oracle Fusion Middleware Performance and Tuning Guide Table 8–8 AM Pool Tuning Parameters Parameter Description jbo.ampool.initpoolsize Specifies the number of application module instances to create when the pool is initialized default is zero. Setting a nonzero initial pool size increases the time to initialize the application, but improves subsequent performance for operations requiring an AM instance. A general guideline is to configure this to 10 more than the anticipated number of concurrent AM instances required to service all users. jbo.ampool.maxpoolsize Specifies the maximum number of application module instances that the pool can allocate default is 4096. The pool can never create more application module instances than this limit imposes. A general guideline is to configure this to 20 more than the initial pool size to allow for some additional growth. jbo.ampool.minavailables ize Specifies the minimum number of available application module instances that the pool monitor should leave in the pool during a resource cleanup operation default is 5. The ideal minimum value for this configuration should be at least 1 to avoid the costs of re-creating the AM pool. Setting this to zero 0 can cause the pool itself to be cleaned up when all instances have been idle for longer than the idle time out. jbo.ampool.maxavailables ize Specifies the ideal maximum number of application module instances in the pool when not under abnormal load default is 25. When the pool monitor wakes up to do resource cleanup, it tries to remove available application module instances to bring the total number of available instances down to this ideal maximum. Instances that have not been used for a period longer than the idle instance time out is cleaned up at this time, and then additional available instances can be removed if necessary to bring the number of available instances down to this size. jbo.recyclethreshold Specifies the maximum number of application module instances in the pool that attempt to preserve session affinity for the next request made by the session that used them last before releasing them to the pool in managed-state mode default is 10. The referenced pool size should always be less than or equal to the maximum pool size. This enables the configured number of available instances to try and remain loyal to the affinity they have with the most recent session that released them in managed state mode. A general guideline is to configure this to the expected number of concurrent users that perform multiple operations with short think times. If there are no users expected to use the application with short think times, then this can be configured to 0 zero to eliminate affinity. jbo.ampool.timetolive Specifies the number of milliseconds that an application module instance lives in the pool. After this time, the instance is a candidate for removal during the next resource cleanup regardless of whether it would bring the number of instances in the pool below minavailablesize The default is 3600000ms or 1 hour. The default value is sufficient for most applications. jbo.ampool.maxinactiveag e Specifies the number of milliseconds after which to consider an inactive application module instance in the pool as a candidate for removal during the next resource cleanup default is 600000ms = 10 minutes. jbo.ampool.monitorsleepi nterval Specifies the length of time in milliseconds between pool resource cleanup default is 600000ms = 10 minutes. While the number of application module instances in the pool should never exceed the maximum pool size, available instances that are candidates for removal from the pool do not get cleaned up until the next time the application module pool monitor wakes up to do its job. jbo.dofailover Specifies whether to disable or enable failover. By default, failover is disabled. To enable failover, set the parameter to true. With failover enabled, the state information is automatically passed when the AM is checked back into the AM pool. This enables any other AM instance to activate the state at any time.