This chapter provides basic guidelines on how to maximize the performance and scalability of the Oracle Application Development Framework (ADF). This chapter covers design, configuration, and deployment performance considerations in the following sections:
This chapter assumes that you are familiar with building ADF applications. To learn about ADF, see the following guides:
Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework
Oracle Fusion Middleware Java EE Developer's Guide for Oracle Application Development Framework
Oracle Application Development Framework (Oracle ADF) is an end-to-end application framework that builds on Java Platform, Enterprise Edition (Java EE) standards and open-source technologies to simplify and accelerate implementing service-oriented applications. Oracle ADF is suitable for enterprise developers who want to create applications that search, display, create, modify, and validate data using web, wireless, desktop, or web services interfaces. If you develop enterprise solutions that search, display, create, modify, and validate data using web, wireless, desktop, or web services interfaces, Oracle ADF can simplify your job. Used in tandem, Oracle JDeveloper 11g and Oracle ADF give you an environment that covers the full development lifecycle from design to deployment, with drag-and-drop data binding, visual UI design, and team development features built-in.
For more information see "Introduction to Oracle ADF" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
Oracle ADF Faces Rich Client (RC) is a set of standard JSF components that includes Ajax (Asynchronous JavaScript and XML) functionality.
While Ajax enables rich client-like applications to run on standard internet technologies, JSF provides server-side control, which reduces the dependency on an abundance of JavaScript often found in typical Ajax applications. Using Apache MyFaces Trinidad as the foundation, Oracle ADF Faces RC adds Ajax functionality, bringing rich Internet application (RIA) capabilities to JSF applications.
Before building, configuring, and deploying ADF applications, review the following topics to achieve optimal performance:
This section discusses the configuration and profiling concepts of the ADF Faces. Configuration options for Oracle ADF Faces are set in the web.xml
file. Most of these have default values that are tuned for performance. Table 8-1 describes some of these configuration options.
Table 8-1 ADF Configuration Options
Parameter | Description |
---|---|
|
Controls whether output should be enhanced for debugging or not. This parameter should be removed or set to |
|
Controls whether ADF faces check for modification date of JSP pages and discard any saved state if the file is changed. This parameter should be removed or set to |
|
Specifies which type of saving ( |
|
Sets the log level on the client side. The default value is |
|
Specifies whether to process assertions on the client side. The default value is |
Note:
When you are profiling or measuring client response time using the Firefox browser, ensure that the Firebug plug-in is disabled. While this plug-in is very useful for getting information about the page and for debugging JavaScript code on the page, it can impact the total response time.For more information on disabling the Firefox Firebug plug-in, see the Firefox Support Home Page at http://support.mozilla.com/en-US/kb/
.
Table 8-2 provides configuration recommendations that may improve performance of ADF Faces:
Table 8-2 Configuration Parameters for ADF Faces
Configuration Recommendation | Description |
---|---|
Use partial page navigation. |
Partial Page Navigation is a feature of the ADF Faces framework that enables navigating from one ADF Faces page to another without a full page transition in the browser.The new page is sent to the client using Partial Page Rendering (PPR)/Ajax channel. The main advantage of partial page navigation over traditional full page navigation is improved performance: the browser no longer re-interprets and re-executes Javascript libraries, and does not spend time for cleanup/initialization of the full page. The performance benefit from this optimization is very big; it should be enabled whenever possible. Some known limitations of this feature are:
|
Use page templates. |
Page templates enable developers to build reusable, data-bound templates that can be used as a shell for any page. A developer can build one or more templates that provide structure and consistency for other developers building web pages. The templates have both static areas on them that cannot be changed when they are used and dynamic areas on them where the developer can place content specific to the page they are building. There are some important considerations when using templates:
|
Enable ADF rich client geometry management. |
ADF Rich Client supports geometry management of the browser layout where parent components are in the UI explicitly. The children components are sized to stretch and fill up available space in the browser. While this feature makes the UI look better, it has a cost. The impact is on the client side where the browser must spend time resizing the components. The components that have geometry management by default are: PanelAccordion PanelStretchLayout PanelTabbed BreadCrumbs NavigationPane PanelSplitter Toolbar Toolbox Table Train Notes:
|
Use the ADF rich client overflow feature. |
ADF Rich Client supports overflow feature. This feature moves the child components to the non-visible overflow area if they cannot fit the page. The components that have built-in support for overflow are: PanelTabbed, BreadCrumbs, NavigationPane, PanelAccordion, Toolbar, and Train. Toolbar should be contained in a Toolbox to handle the overflow. While there were several optimizations done to reduce the cost of overflow, it is necessary to pay special attention to the number of child components and complexity of each of them in the overflow component. Sometimes it is a good practice to set a big enough initial size of the overflow component such that overflow does not happen in most cases. |
Use ADF Rich Client Partial Page Rendering (PPR). |
ADF Rich Client is based on Asynchronous JavaScript and XML (Ajax) development technique. Ajax is a web development technique for creating interactive web applications, where web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, without the whole web page being reloaded. The effect is to improve a web page's interactivity, speed, and usability. With ADF Faces, the feature that delivers the Ajax partial page refresh behavior is called partial page rendering (PPR). PPR enables small areas of a page to be refreshed without having to redraw the entire page. For example, an output component can display what a user has chosen or entered in an input component or a command link or button can cause another component on the page to be refreshed. Two main Ajax patterns are implemented with partial page rendering (PPR):
While the framework builds in native component refresh, cross-component refresh has to be done by developers in certain cases. Cross-component refresh is implemented declaratively or programmatically by the application developer defining which components are to trigger a partial update and which other components are to act as partial listeners, and so be updated. Using cross-component refresh and implementing it correctly is one of the best ways to improve client-side response time. While designing the UI page always think about what should happen when the use clicks a command button. Is it needed for the whole page to be refreshed or just an output text field? What should happen if the value in some field is updated? For more information, refer to Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework). Consider a typical situation in which a page includes an
The steps above achieve PPR using a command button to trigger the partial page refresh. The main reason why partial page rendering can significantly boost the performance is that full page refresh does not happen and the framework artifacts (such as ADF Rich Client JS library, and style sheets) are not reloaded and only a small part of page is refreshed. In several cases, this means no extra data is fetched or no geometry management. The ADF Rich Client has shown that partial page rendering results in the best client-side performance. Besides the impact on the client side, server-side processing can be faster and can have better server-side throughput and scalability. |
Use ADF rich client navigation. |
ADF Rich Client has an extensive support for navigation. One of the common use cases is tabbed navigation. This is currently supported by components like navigationPane which can bind to xmlMenuModel to easily define navigation. There is one drawback in this approach, however. It results in a full page refresh every time the user switches the tab. One option is to use panelTabbed instead. panelTabbed has built-in support for partial page rendering of the tabbed content without requiring any developer work. However, panelTabbed cannot bind to any navigational model and the content has to be available from within the page, so it has limited applicability. |
Cache resources. |
Developers are strongly encouraged to ensure that any resources that can be cached (images, CSS, JavaScript) have their cache headers specified appropriately. Also, client requests for missing resources on the server result in addition round trips to the server. To avoid this, make sure all the resources are present on the server. |
Reduce the size of state token cache |
Property defined in web.xml org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS in "token"-based client-side state saving, chooses how many tokens should be preserved at any one time. The default value is 15. When this is exceeded, state will have effectively been "forgotten" for the least recently viewed pages, which can impact users that actively use the Back button or that have multiple windows open simultaneously. In order to reduce live memory per session, consider reducing this value to 2. Reducing the state token cache to 2 means one Back button click is supported. For applications without support for Back button this value should be set to 1. |
Define custom styles at the top of the page. |
A common developer task is to define custom styles inside a regular page or template page. Since most browsers use progressive scanning of the page, a late introduction of styles forces the browser to recompute the page. This impacts the page layout performance. For better performance, define styles at the top of the page and possibly wrap them inside the ADF group tag. An HTML page basically has two parts, the "head" and the "body". When you put an To get a component (or static CDATA content) to display in the "head", use the "metaContainer" facet as follows: <af:document title="#{attrs.documentTitle}" theme="dark"> <f:facet name="metaContainer"> <af:group><![CDATA[ <style type="text/css"> .TabletNavigationGlobal { text-align: right; padding-left: 0px; padding-right: 10px; white-space: nowrap; } HTML[dir=rtl] .TabletNavigationGlobal { text-align: left; padding-left: 10px; padding-right: 0px; } </style> ]]> <af:facetRef facetName="metaContainer"/> </af:group> </f:facet> <af:form ...> <af:facetRef facetName="body"/> </af:form> </af:document> If you use page templates, consider including See the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework for details about |
Optimize custom JavaScript code. |
ADF Rich Client uses JavaScript on the client side. The framework itself provides most of the functionality needed. However, you may have to write custom JavaScript code. To get the best performance, consider bundling the JavaScript code into one JS lib (one JavaScript file) and deliver it to the client. The easiest approach is to use the ADF tag: < If most pages require custom JavaScript code, the tag should be included in the application template. Otherwise, including it in particular pages can result in better performance. If custom the JavaScript code lib file becomes too big, then consider splitting it into meaningful pieces and include only the pieces needed by the page.Overall, this approach is faster since the browser cache is used and the html content of the page is smaller. |
Disable debug output mode. |
The Set the |
Disable test automation. |
Enabling test automation parameter Set the |
Disable animation. |
ADF Rich Client framework has client side animation enabled by default. Animation is introduced to provide an enhanced user experience. Some of the components, like popup table, have animation set for some of the operations. While using animation can improve the user experience, it can increase the response time when an action is executed. If speed is the biggest concern, then animation can be disabled by setting the flag in |
Disable client-side assertions. |
Assertions on client-side code base can have a significant impact on client-side performance. Set the parameter value to |
Disable JavaScript Profiler. |
When the JavaScript |
Disable resource debug mode. |
When resource debug mode is enabled, the HTTP response headers do not tell the browser (or WebCache) that resources (JS libraries, CSS style sheets, or images) can be cached. Disable the |
Disable timestamp checking. |
The Ensure that the parameter value |
Disable checking for CSS file modifications. |
The |
Enable content compression. |
By default, style classes that are rendered are compressed to reduce page size. In production environments, make sure you remove the For debugging, turn off the style class content compression. You can do this by setting the |
Enable JavaScript obfuscation. |
ADF Faces supports a run time option for providing a non-obfuscated version of the JavaScript library. The obfuscated version is supplied by default, but the non-obfuscated version is supplied for development builds. Obfuscation reduces the overall size of the JavaScript library by about 50%. To provide an obfuscated ADF Faces build, set the There are two ways to check that the code is obfuscated using Firefox with Firebug enabled: Check the download size:
Check the source:
|
Enable library partitioning. |
In the Oracle 11g Release, library partitioning is on by default. In previous versions library partitioning was off by default. Ensure that the library partitioning is on by validating the |
Table 8-3 provides configuration recommendations for ADF Faces Component Attributes:
Table 8-3 ADF Faces Component Attributes
Configuration Recommendation | Description |
---|---|
Use the "immediate" attribute. |
ADF Rich Client components have an
ADF Rich Client is built on top of JSF and uses standard JSF lifecycle. See "Understanding the JSF and ADF Faces Lifecycles" in Oracle Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework. There are some important issues associated with the Note that this is an advanced feature. Most of the performance improvements can be achieved using the |
Use the "visible" and "rendered" attributes. |
All ADF Faces Rich Client display components have two properties that dictate how the component is displayed on the page:
The EL expression is commonly used to control these properties. For better performance, consider setting the component to not rendered instead of not visible, assuming there is no client interaction with the component. Making a component not rendered can improve server performance and client response time since the component does not have client side representation. |
Use client-side events. |
ADF Rich Client framework provides the client-side event model based on component-level events rather than DOM level. The client-side event model is a very useful feature that can speed up the application. Review the following performance considerations:
|
Use the "id" attribute. |
The "id" attribute should not be longer than 7 characters in length. This is particularly important for naming containers. A long id can impact performance as the amount of HTML that must be sent down to the client is impacted by the length of the ids. |
Use client-side components. |
ADF Rich Client framework has client-side components that play a role in client-side event handling and component behavior. The For more information, see "Client-side Components" in Oracle Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework. |
Set the |
Setting |
Table, Tree, and TreeTable are some of the most complex, and frequently used, components. Since these components can include large sets of data, they can be the common source of performance problems. Table 8-4 provides some performance recommendations.
Table 8-4 Table and Tree Component Configurations
Configuration Recommendation | Description |
---|---|
Modify table fetch size. |
Tables have a fetch size which defines the number of rows to be sent to the client in one round-trip. To get the best performance, keep this number low while still allowing enough rows to fulfill the initial table view port. This ensures the best performance while eliminating extra server requests. In addition, consider keeping the table fetch size and iterator range size in sync. By default, the table fetch size is set to the EL expression For more information see "Using Tables and Trees" in Oracle Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework. |
Disable column stretching. |
Columns in the table and treeTable components can be stretched so that there is no unused space between the end of the last column and the edge of the table or treeTable component. This feature is turned off by default due to potential performance impacts. Turning this feature on may have a performance impact on the client rendering time, so use caution when enabling this feature with complex tables. For more information see "Use Column Stretching" in Oracle Fusion Applications Developer's Guide. |
Consider using header rows and frozen columns only when necessary. |
The table component provides features that enable you to set the row Header and frozen columns. These options can provide a well-designed interface which can lead to a good user experience. However, they can impact client-side performance. To get the best performance for table components, use these options only when they are needed. |
autoSuggest
is a feature that can be enabled for inputText, inputListOfValues, and inputComboboxListOfValues components. When the user types characters in the input field, the component displays a list of suggested items. The feature performs a query in the database table to filter the results. In order to speed up database processing, a database index should be created on the column for which autosuggest is enabled. This improves the component's response times especially when the database table has a large number of rows.
Data for Table, Tree, and other stamped components can be delivered immediately or lazily. By default, lazy delivery is used. This means that data is not delivered in the initial response from the server. Rather, after the initial page is rendered, the client asks the server for the data and gets it as a response to the second request.
In the case of immediate delivery, data can be in line with the response to the page request. It is important to note that data delivery is per component and not per page. This means that these two can be mixed on the same page.
When choosing between these two options, consider the following:
Lazy Delivery (default) | Lazy delivery should be used for tables, or other stamped components, which are known to have slow fetch time. The examples are stamped components are the ones based on data controls using webservices calls or other data controls with slow data fetch. Lazy delivery can also be used on pages where content is not immediately visible unless the user scrolls down to it. In this case the time to deliver the visible context to the client will be shorter, and the user perceives better performance.
Lazy delivery is implemented using data streaming technique. The advantage of this approach is that the server has the ability to execute data fetches in parallel and stream data back to the client as soon as the data is available. The technique performs very well for a page with two tables, one that returns data very quickly and one that returns data very slowly. Users see the data for the fast table as soon as the data is available. Executing data fetches in parallel also speeds up the total time to fetch data. This gives an advantage to lazy loading in cases of multiple, and possibly slow, data fetches. While streaming is the default mechanisms to deliver data in lazy mode, parallel execution of data controls is not. In order to enable parallel execution, open the page definition and change In certain situations, the advantage of parallel execution is faster response time. Parallel execution could potentially use more resources due to multiple threads executing request in parallel and possibly more database connections will be opened. Consider using parallel execution only when there are multiple slow components on the page and the stamped components belong to different data control frames (such as isolated taskflows). Since parallel execution synchronizes on the data control frame level, when there is a single data control frame parallel execution may not improve performance. |
---|---|
Immediate Delivery | Immediate delivery (contentDelivery="immediate" ) should be used if table data control is fast, or if it returns a small set of data. In these cases the response time be faster than using lazy delivery.
Another advantage of immediate delivery is less server resource usage, compared to lazy delivery. Immediate delivery sends only one request to the server, which results in lower CPU and memory usage on the server for the given user interaction. |
DVT components are data visualization components built on top of ADF Rich Client components. DVT components include graphs, gauges, Gantt charts, pivot tables and maps. Table 8-5 provides some configuration recommendations for DVT components:
Table 8-5 DVT Component Configurations
Configuration Recommendation | Description |
---|---|
Modify the RangeSize attribute. |
The RangeSize attribute defines the number of rows to return simultaneously. A RangeSize value of -1 causes the iterator to return all the rows. Using a lower value may improve performance, but it may be harder to stop the data and any data beyond rangeSize is not available in the view. |
Use horizontal text instead of vertical text. |
By default, pivot tables use horizontal text for column headers. However, there is an option to use vertical text as well. Vertical text can be used by specifying a CSS style for the header format such as:
While vertical text can look better in some cases, it has a performance impact when the Firefox browser is used. The problem is that vertical text is not native in Firefox as it is in Internet Explorer. To show vertical text, the pivot table uses images produced by GaugeServlet. These images cannot be cached as the text is dynamic and depends on the binding value. Due to this, every rendering of the pivot table incurs extra round-trips to the server to fetch the images, which impact network traffic, server memory, and CPU. To have the best performance, consider using horizontal text instead of vertical text. |
Oracle ADF Server components consist of the non-UI components within ADF. These include the ADF implementations of the model layer (ADFm), business services layer (ADFbc), and controller layer (ADFc). As the server components are highly configurable, it is important to choose the combination of configurations that best suits the available resources with the specified application performance and functionality.
View objects (VOs) provide many tuning options to enable a developer to tailor the View Object to the application's specific needs. View Objects should be configured to use the minimal feature set required to fulfill the functional requirement. The Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework provides detailed information on tuning View Objects. Provided here are some tips pertaining to View Object performance.
To maximize View Object performance, the View Object should match the intended usage. For instance, data retrieved for a list of values pick-list is typically read-only, so a read-only View Object should be used to query this data. Tailoring the View Object to the specific needs of the application can improve performance, memory usage, CPU usage, and network usage.
View Object Type | Description |
---|---|
Read-only View Objects | Consider using a read-only View Object if the View Object does not have to insert or update data. There are two options for read-only View Objects:
Non-updatable EO-based View Objects offer the advantage of a customizable select list at run time which retrieve attributes needed in the UI, data reads from local cache (instead of re-executing a database query), and data consistency with other updatable View Objects based on the same EO. Expert-mode View Objects have the ability to perform SQL operations not supported by EOs and avoid the small performance impact from coordinating View Object and EO rows. EO-based View Objects can be marked non-updatable by deselecting the "updatable" option in the selected EO for the View Object, which can also be done by adding the parameter |
Insert-only View Objects | For View Objects that are used only for inserting records, you can prevent unnecessary select queries from being executed when using the View Object. To do this, set the option No Rows in the Retrieve from the Database group box in the View Objects Overview tab. This sets MaxFetchSize to 0 (zero) for the View Object definition. |
run time-created View Objects | View Objects can be created at run time using the createViewObjectFromQueryStmt() API on the AM. However, avoid using run time-created View Objects unless absolutely necessary due to potential performance impacts and complexity of tuning. |
View Object performance is largely dependent on how the view object is configured to fetch data. If the fetch options are not tuned correctly for the application, then the view object may fetch an excessive amount of data or may take too many round-trips to the database. Fetch options can be configured through the Retrieve from the Database group box in the View Object dialog Figure 8-1.
Fetch Option | Description |
---|---|
Fetch Mode | The default fetch option is the All Rows option, which is retrieved as needed (FetchMode="FETCH_AS_NEEDED" ) or all at once (FetchMode="FETCH_ALL" ), depending on which option is appropriate. The As Needed option ensures that an executeQuery() operation on the view object initially retrieves only as many rows as necessary to fill the first page of a display. The number of rows is set based on the view object's range size. |
Fetch Size | In conjunction with the fetch mode option, the Batches field controls the number of records fetched simultaneously from the database (FetchSize in the View Object, XML). The default value is 1, which may impact performance unless only 1 row is fetched. The suggested configuration is to set this value to n+1 where n is the number of rows to be displayed in the user interface.
Note that for DVT objects, Fetch Size should be n+1 where n is either rangeSize or the likely maximum rowset size if rangeSize is -1. |
Max Fetch Size | The default max fetch size for a View Object is -1, which means that there is no limit to the number of rows the View Object can fetch. Setting a max fetch size of 0 (zero) makes the View Object insert-only. In cases where the result set should only contain n rows of data, the option Only Up to Row Number should be selected and set or call setMaxFetchSize( N) to set this programmatically. To set this manually, add the parameter MaxFetchSize to the View Object XML.
For View Objects whose WHERE clause expects to retrieve a single row, set the option At Most One Row. This option ensures that the view object knows not to expect any more rows and skips its normal test for that situation. In this case no select query is issued and no rows are fetched. Max fetch size can also be used to limit the impact from an non-selective query that may return hundreds (or thousands) of rows. In such cases, specifying the max fetch size limits the number of rows that can be fetched and stored into memory. |
Forward-Only Mode | If a data set is only traversed going forward, then forward-only mode can help performance when iterating through the data set. This can be configured by programmatically calling setForwardOnly(true) on the View Object. Setting forward-only can also prevent caching previous sets of rows as the data set is traversed. |
Table 8-6 provides additional tuning considerations when using the View Object:
Table 8-6 Additional View Object Configurations
Configuration Recommendation | Description |
---|---|
Optimize large data sets. |
View Objects provide a mechanism to page through large data sets so that a user can jump to a specific page in the results. This is configured by calling |
Disable "spillover" configurations when possible. |
You can use the data source as "virtual memory" when the JVM container runs out of memory. By default this is disabled and can be enabled (if needed) by setting |
Review SQL style configuration. |
If the generic SQL92 SQL style is used to connect to generic SQL92-compliant database, then some View Object tuning options do not apply. The View Object fetch size is one such tuning option. When SQL92 SQL style is used, the fetch size defaults to 10 rows, regardless of what is configured for the View Object. The SQL style is set when defining the database connection. By default when defining an Oracle database connection, the SQL style can be |
Use bind variables for view object queries. |
If the query associated with the View Object contains values that may change from execution to execution, consider using bind variables. This may help to avoid re-parsing the query on the database. Bind variables can be added to the View Object in the Query section of the View Object definition. |
Use query optimizer hints for view object queries. |
The View Object can pass hints to the database to influence which execution plan to use for the associated query. The optimizer hints can be specified in the Retrieve from the Database group box. |
Use dynamic SQL generation. |
View Objects can be configured to dynamically generate SQL statements at run time instead of defining the SQL at design time. A View Object instance, configured with generating SQL statements dynamically, can avoid re-querying a database. This is especially true during page navigation if a subset of all attributes with the same key Entity Object list is used in the subsequent page navigation. Performance can be improved by activating a superset of all the required attributes to eliminate a subsequent query execution. |
Batch processing enables multiple inserts, updates, and deletes to be processed together when sending the operations to the database. Enabling this feature is done on the Entity Object (EO) by either selecting the "Use Update Batching" check box in the Tuning section of the EO's General tab, or by directly modifying the EO's 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"
).
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 page's page definition XML.
Designing an application's 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 Developer's Guide for Oracle Application Development Framework.
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 Developer's Guide for Oracle Application Development Framework.
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 (-D
property=
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.
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 Developer's Guide for Oracle Application Development Framework. |
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 Developer's 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-8 AM Pool Tuning Parameters
Parameter | Description |
---|---|
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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 |
|
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). |
|
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. |
|
Specifies whether to disable or enable failover. By default, failover is disabled. To enable failover, set the parameter to |
|
Specifies the locking mode ( |
|
Specifies whether the AM instance can be disconnected from the database connection when the AM instance is returned to the AM pool. This enables an application to size the AM pool larger than the database connection pool. The default is |
|
When used in conjunction with |
The following AM pool sizing parameters control the AM pool size. Consider adjusting these values to tune memory or CPU usage.
For parameters that can be configured for memory-constrained systems, see Table 8-9.
Table 8-9 AM Pool Sizing Configurations - Memory Considerations
Parameter | Description |
---|---|
|
Set this to a low value to conserve memory at the cost of slower performance when additional AM instances are required. The default value of 0 (zero) does not create any AM instances when the AM pool is initialized. |
|
Configure this to prevent the number of AM instance from exceeding the determined value. However, if this is set too low, then some users may see an error accessing the application if no AM instances are available. |
|
Set to 0 (zero) to shrink the pool to contain no instances when all instances have been idle for longer than the idle time out after a resource cleanup. However, a setting of 1 is commonly used to avoid the costs of re-creating the AM pool. |
|
Configure this to leave the maximum number of available instances specified after a resource cleanup. |
For parameters that can be configured to reduce the load on the CPU to some extent through a few parameters, see Table 8-10.
Table 8-10 AM Pool Sizing Configurations - CPU Considerations
Parameter | Description |
---|---|
|
Set this value to the number of AM instances you want the application pool to start with. Creating AM instances during initialization takes the CPU processing costs of creating AM instances during the initialization instead of on-demand when additional AM instances are required. |
|
Configure this value to maintain the AM instance's affinity to a user's session. Maintaining this affinity as much as possible save the CPU processing cost of needing to switch an AM instance from one user session to another. |
These parameters affect the frequency and characteristics for AM pool resource cleanups. Details about resource cleanup can be found in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
For memory-constrained systems, configure the AM pool to clean up more AM instances more frequently so that the memory consumed by the AM instance can be freed for other purposes. However, reducing the number of available AM instances and increasing the frequency of cleanups can result in higher CPU usage and longer response times. See Table 8-11 for more information.
Table 8-11 AM Pool Resource Cleanup Configurations - Memory Considerations
Parameter | Description |
---|---|
|
A setting of 0 (zero) shrinks the pool to contain no instances when all instances have been idle for longer than the idle time out. However, a setting of 1 is commonly used to avoid the costs of re-creating the AM pool |
|
A lower value generally results in more AM instances being removed from the pool on a cleanup. |
|
A lower value reduces the time an AM instance can exist before it must be removed at the next resource cleanup. |
|
A low value results in more AM instances being marked as a candidate for removal at the next resource cleanup. |
|
This controls how frequent resource cleanups can be triggered. Configuring a lower interval results in inactive AM instances being removed more frequently to save memory. |
The AM pool can be configured to reduce the need for CPU processing by allowing more AM instances to exist in the pool for longer periods of time. This generally comes at the cost of consuming more memory.
Table 8-12 AM Pool Resource Cleanup Configurations - CPU Considerations
Parameter | Description |
---|---|
|
Setting these to a higher value leaves more idle instances in the pool, so that AM instances do not have to be recreated at a later time. However, the values should not be set excessively high to keep more AM instances than can be required at maximum load. |
|
A higher value increases the time an AM instance can exist before it must be removed at the next resource cleanup. |
|
A higher value results in fewer AM instances being marked as a candidate for removal at the next resource cleanup. |
|
Configuring a higher interval results in less frequent resource cleanups. |
Adding regions to a page can be a powerful addition to the application. However, regions can be a resource-intensive component on the page. For better performance, consider using regions only when the specific functionality is required.
If the application contains static data that can be reused across the application, the cache data can be collected using a shared application module. More information on creating and using shared application modules can be found in "Sharing Application Module View Instances" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
For resource-intensive validations on entity attributes, consider using preconditions to selectively apply the validations only when needed. The cost of validation must be weighted against the cost of the precondition to determine if the precondition is beneficial to the performance. More information on specifying preconditions for validation can be found in "How to Set Preconditions for Validation" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.