Data Delivery - Lazy versus Immediate

8-18 Oracle Fusion Middleware Performance and Tuning Guide Tuning section of the EOs General tab, or by directly modifying the EOs XML file and adding the parameter BatchThreshold with the specified batch size to the Entity attribute. The BatchThreshold value is the threshold at which a group of operations can be batched instead of performing each operation one at a time. If the threshold is not exceeded, then rows may be affected one at a time. On the other hand, more rows than specified by the threshold can be batched into a single batch. Note that the BatchThreshold configuration for the EO is not compatible if an attribute in the EO exists with the configuration to refresh after insert RetrievedOnInsert=true or update RetrievedOnUpdate=true.

8.3.3 RangeSize Tuning

This parameter controls the number of records ADFm requests from the BC layer simultaneously. The default RangeSize is 25 records. Consider setting this value to the number of records to be displayed in the UI simultaneously for the View Object so that the number of round-trips between the model and BC layers is reduced to one. This is configured in the Iterator attribute of the corresponding pages page definition XML.

8.3.4 Application Module Design Considerations

Designing an applications module granularity is an important consideration that can significantly impact performance and scalability. It is important to note that each root application module generally holds its own database connection. If a user session consumes multiple root application modules, then that user session can potentially hold multiple database connections simultaneously. This can occur even if the connections are not actively being used, due to the general affinity maintained between an application module and a user session. To reduce the possibility that a user can hold multiple connections at once, consider the following options: ■ Design larger application modules to encompass all of the functionality that a user needs. ■ Nest smaller application modules under a single root application module so that the same database connection can be shared among the nested application modules. ■ Use lazy loading for application modules. In the Application Module tuning section, customize runtime instantiation behavior to use lazy loading. Lazy loading can also be set JVM-wide by adding the following JVM argument: -Djbo.load.components.lazily=true More information can be found in the What You May Need to Know About Application Module Granularity and Defining Nested Application Modules sections of Oracle Fusion Middleware Fusion Developers Guide for Oracle Application Development Framework.

8.3.5 Application Module Pooling

Application module AM pooling enables multiple users to share several application module instances. The configurations for the AM pool vary depending on the expected usage of the application. For detailed explanations of the different AM pool configurations, see Tuning Application Module Pools in Oracle Fusion Middleware Fusion Developers Guide for Oracle Application Development Framework. 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.