Skip Headers
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2)
B14032-03
  Go To Documentation Library
Library
Go To Product List
Product
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
 

10.2 Tuning OracleAS Forms Services Applications

An application developer can take steps to ensure that maximum benefits are gained from Forms Server's built-in architectural optimizations. The remainder of this chapter discusses key performance issues that affect many applications and how developers can improve performance by tuning applications to exploit Forms Server features.

10.2.1 Location of the Oracle Application Server Forms Services with Respect to the Data Server

The Forms Java client is only responsible to display the GUI objects. All of the Oracle Forms logic runs in Oracle Application Server Forms Services, on the middle tier. This includes inserting or updating the data to the database, querying data from the database, executing stored procedures on the database, and so on. Therefore, it is important to have a high-speed connection between the application server and the database server.

All of this interaction takes place without any communication to the Forms Java client. Only when there is a change on the screen is there any traffic between the client and Forms Services. This allows Oracle Forms applications to run across slower networks, such as with modems or satellites.

The configuration in Figure 10-1, displays how Forms Services and the database server are co-located in a data center.

Figure 10-1 Co-Locating the OracleAS Forms Services and Database Server

Forms Services and database collocated in a data center.

10.2.2 Minimizing the Application Startup Time

First impressions are important, and a key criterion for any user is the time it takes to load an application. Startup time is regarded as overhead. It also sets an expectation of future performance. When a business uses thin-client technologies, the required additional overhead of loading client code may have a negative impact on users. Therefore, it is important to minimize load time wherever possible.

After requesting an Oracle Forms application, several steps must be completed before the application is ready for use:

  1. Invoke Java Virtual Machine (JVM).

  2. Load all initial Java client classes, and authenticate security of classes.

  3. Display splash screen.

  4. Initialize form:

    1. Load additional Java classes, as required.

    2. Authenticate security of classes.

    3. Render boilerplate objects and images.

    4. Render all elements on the initial screen.

  5. Remove splash screen.

  6. Form is ready for use.

An application developer has little influence on the time it takes to launch the JVM. However, the Java deployment model and the structure of the Oracle Forms Developer Java client allow the developer to decide which Java classes to load and how. This, in turn, minimizes the load time required for Java classes.

The Java client requires a core set of classes for basic functionality (such as opening a window) and additional classes for specific display objects (such as LOV items). These classes must initially reside on the server, but the following techniques can be used to improve the time it takes to load these classes into the client's JVM:

10.2.2.1 Using Java Files

Java provides the Java Archive (Jar) mechanism to create files that allow classes to be grouped together and then compressed (zipped) for efficient delivery across the network to the client. Once used on the client, the files are cached for future use.

Oracle Application Server Forms Services provides the following pre-configured Jar files to support typical deployment scenarios.

10.2.2.1.1 Oracle JInitiator

The following are the Jar files provided for use with Oracle JInitiator:

  • frmall.jar - includes all required classes

  • frmall_jinit.jar - same as frmall.jar but is optimized for use with Oracle JInitiator (this is the default)

  • frmmain.jar - contains fewer classes than frmall.jar. The other classes are downloaded as needed using a deferred mechanism. This gives a smaller download and a faster startup time.

To specify one or more Jar files, use the archive_jini setting in the named configuration section of the Forms Configuration file (formsweb.cfg). For example,

[MyApp]
archive_jini=frmall_jinit.jar, icons.jar

Your archive_jini setting must use only one of the three Jar files listed, above. It may also contain any additional custom Jar files that your application uses (for example, icons.jar, as shown in the previous example). Each application can use its own archive_jini setting.

The following Jar files contain the deferred classes that are missing from frmmain.jar. They will be downloaded automatically as they are needed, so there is no need to reference them in the archive_jini setting. They are already present in frmall.jar and frmall_jinit.jar, so they are only used if you use frmmain.jar.

  • frmoracle_laf.jar – classes for the Oracle Look-And-Feel

  • frmgeneric_laf.jar – classes for the generic (standard) Look-And-Feel

  • frmresources.jar – resource classes for languages other than US English.

    The English resource classes are contained in frmall.jar, frmall_jinit.jar, and frmmain.jar. frmresources.jar will be loaded if a language other than US English is used. Note that this Jar file contains the resources for all languages other than English. Therefore you will have either the US English resource classes, or all of the language resource classes.

For more information about Oracle JInitiator, see Appendix B, "JInitiator".

10.2.2.1.2 All other cases (for example, Sun's Java Plug-in)

The following Jar file is provided for Java Virtual Machines (JVMs) other than Jinitiator or the IE native JVM:

  • frmall.jar - includes all required classes

To specify one or more Jar files, use the archive setting in the named configuration section of the Forms Configuration file (formsweb.cfg). For example,

[MyApp]
archive=frmall.jar

10.2.2.2 Using Caching

Both of the supported JVMs for Oracle Application Server Forms Services (Oracle JInitiator and Oracle JDK) support the caching of Jar files. When the JVM references a class, it first checks the local client cache to see if the class exists in a pre-cached Jar file. If the class exists in cache, JVM checks the server to see if there is a more current version of the Jar file. If there isn't, the class is loaded from the local cache rather than from across the network.

Be sure that the cache is of proper size to maximize its effectiveness. Too small a cache size may cause valid Jar files to be overwritten, thereby requiring that another Jar file be downloaded when the application is run again. The default cache size is 20MB. This size should be compared with the size of the cache contents after successfully running the application.

Jar files are cached relative to the host from which they were loaded. This has implications in a load-balancing architecture where identical Jar files from different servers can fill the cache. By having Jar files in a central location and by having them referenced for each server in the load-balancing configuration, the developer can ensure that only one copy of each Jar file is maintained in the client's cache. A consequence of this technique is that certain classes within the Jar file must be signed to enable connections back to servers other than the one from which they were loaded. The Oracle-supplied Jar files already pre-sign the classes.

10.2.3 Reducing the Required Network Bandwidth

The developer can design the application to maximize data stream compression by using message diff-ing, which sends along only the information that differs from one message to another. The following steps can be taken to reduce the differences between messages:

  • Control the order in which messages are sent. The order in which messages are sent is governed by two criteria:

    • For the initial display, the display order in the Object Navigator

    • During execution, the order of program changes to item properties

Where the result does not impact usability, you should strive to place similar objects that are on the same canvas after each other in the Object Navigator. For example, place buttons with buttons, text items with text items, and so on. (If you use the item property Next Navigation Item, the same order of navigation will be used for the items in the Form.) By ordering similar items together on the Object Navigator, the item properties sent to the client to display the first Form will include many similar items in consecutive order, which allows the message diff-ing algorithm to function efficiently.
In addition, when triggers or other logic are used to alter item properties, then you should group properties of similar items together before altering the item properties of another display type. For example:
    set_item_property(text_item1_id, FONT_WEIGHT, FONT_BOLD);
    set_item_property(text_item2_id, FONT_WEIGHT, FONT_BOLD);
    set_item_property(text_item3_id, FONT_WEIGHT, FONT_BOLD);
    set_item_property(button_item1_id, LABEL, 'Exit');
    ...
  • Promote similarities between objects. Using similar objects improves message diff-ing effectiveness (in addition to being more visually appealing to the user). The following steps encourage consistency between objects:

    • Accept default values for properties, and change only those attributes needed for the object.

    • Use Smart Classes to describe groups of objects.

    • Lock the look-and-feel into a small number of visual attributes.

  • Reduce the use of boilerplate text. As a developer, you should use the PROMPT item property rather than boilerplate text wherever applicable. Forms Developer 6.0 and higher includes the Associate Prompt feature, which allows boilerplate text to be re-designated as the prompt for a given item.

  • Reduce the use of boilerplate items (such as arcs, circles, and polygons). All boilerplate items for a given Form are loaded at Form initialization. Boilerplate items take time to load and use resources on the client whether they are displayed or not. Common boilerplate items, namely rectangles and lines, are optimized. Therefore, restricting the application to these basic boilerplate items reduces network bandwidth and client resources while improving startup times.

  • Keep navigation to a minimum. An Event Bundle is sent each time a navigation event finishes, whether the navigation extends over two objects or many more. Design Forms that do not require the user to navigate through fields when default values are being accepted. A Form should encourage the user to quickly exit once the Form is complete, which causes all additional navigation events to fire as one Event Bundle.

  • Reduce the time to draw the initial screen. Once the Java client has loaded the required classes, it must load and initialize all of the objects to be displayed before it can display the initial screen. By keeping the number of items to a minimum, the initial screen is populated and displayed to the user more promptly. Techniques that reduce the time to draw the initial screen include:

    • Providing a login screen for the application with a restricted set of objects (such as a title, small logo, username, and password).

    • On the Form's initial display, hiding elements not immediately required. Use the canvas properties:

      RAISE ON ENTRY = YES (Canvas only)

      Pay attention to TAB canvases that consist of several sheets where only one will ever be displayed. For responsive switching between tabs, all items for all sheets on the canvas are loaded, including those that are hidden behind the initial tab. Consequently, the time taken to load and initialize a TAB canvas is related to all objects on the canvas and not just to those initially visible.


      Tip:

      When using Tab canvases, use stacked canvases and display the right canvas in the when-tab-page-changed trigger. Remember to set the properties RAISE ON ENTRY = YES and VISIBLE = NO for all the canvases not displayed in the first screen.

  • Disable MENU_BUFFERING. By default, MENU_BUFFERING is set to True. This means that changes to a menu are buffered for a future "synchronize" event when the altered menu is re-transmitted in full. (Most applications make either many simultaneous changes to a menu or none at all. Therefore, sending the entire menu at once is the most efficient method of updating the menu on the client.) However, a given application may make only minimal changes to a menu. In this case, it may be more efficient to send each change as it happens. You can achieve this using the statement:

    Set_Application_Property (MENU_BUFFERING, 'false');
    
    
Menu buffering applies only to the menu properties of LABEL, ICON, VISIBLE, and CHECKED. An ENABLE/DISABLE event is always sent and does not entail the retransmission of an entire menu.

10.2.4 Other Techniques to Improve Performance

The following techniques may further reduce the resources required to execute an application:

  • Examine timers and replace with JavaBeans. When a timer fires, an asynchronous event is generated. There may not be other events in the queue to bundle with this event. Although a timer is only a few bytes in size, a timer firing every second generates 60 network trips a minute and almost 30,000 packets in a typical working day. Many timers are used to provide clocks or animation. Replace these components with self-contained JavaBeans that achieve the same effect without requiring the intervention of Forms Services and the network.

  • Consider localizing the validation of input items. It is common practice to process input to an item using a When-Validate-Item trigger. The trigger itself is processed on the Forms Services. You should consider using pluggable Java components to replace the default functionality of standard client items, such as text boxes. Then, validation of items, such as date or max/min values, are contained within the item. This technique opens up opportunities for more complex, application-specific validation like automatic formatting of input, such as telephone numbers with the format (XXX) XXX-XXXX.

  • Reduce the application to many smaller forms, rather than one large form. By providing a fine-grained application, the user's navigation defines which objects are loaded and initialized from the Forms Services. With large Forms, the danger is that the application is delayed while objects are initialized, many of which may never be referenced. When chaining Forms together, consider using the built-ins OPEN_FORM and NEW_FORM:

    • With OPEN_FORM, the calling Form is left open on the client and the server, so that the additional Form on both the client and the server consumes more memory. However, if the Form is already in use by another user, then the increase in server memory is limited to just the data segments. When the user returns to the initial Form, it already resides in local memory and requires no additional network traffic to redisplay.

    • With NEW_FORM, the calling Form is closed on the client and the server, and all object properties are destroyed. Consequently, it consumes less memory on the server and client. Returning to the initial Form requires that it be downloaded again to the client, which requires network resources and startup time delays. Use OPEN_FORM to display the next Form in an application unless it is unlikely that the initial form will be called again (such as a login form).

  • Avoid unnecessary graphics and images. Wherever possible, reduce the number of image items and background images displayed in your applications. Each time an image is displayed to application users, the image must be downloaded from the application server to the user's Web browser. To display a company logo with your Web application, include the image in the HTML file that downloads at application startup. Do this instead of including it as a background image in the application. As a background image, it must be retrieved from the database or filesystem and downloaded repeatedly to users' computers.