Skip Headers

Oracle9iAS Forms Services Deployment Guide
Release 9.0.2

Part Number A92175-01
Go To Documentation Library
Go To Product List
Solution Area
Go To Table Of Contents
Go To Index

Go to previous page Go to next page

Performance Tuning Considerations


This chapter describes the tuning considerations that arise when you use Oracle9iAS Forms Services to deploy an application. This chapter looks at the network and resources on the application server and includes the following sections:

Tuning the connection between Oracle9iAS Forms Services and the database server is beyond the scope of this chapter.

Built-in Optimization Features of Forms Services

The Oracle9iAS Forms Services and Java client include several optimizations that fit broadly into the following categories:

Minimizing Client Resource Requirements

The Java client is primarily responsible for rendering the application display. It has no embedded application logic. Once loaded, a Java client can display multiple forms simultaneously. Using a generic Java client for all Oracle9i Forms applications requires fewer resources on the client when compared to having a customized Java client for each application.

The Java client is structured around many Java classes. These are grouped into functional subcomponents, such as displaying the splash screen, communicating with the network, and changing the look-and-feel. Functional subcomponents allow the Oracle9i Forms Developer and the Java Virtual Machine (JVM) to load functionality as it is needed, rather than downloading all of the functionality classes at once.

Minimizing Forms Services Resource Requirements

When a form definition is loaded from an FMX file, the profile of the executing process can be summarized as:

Of these, only the Data Segments section is unique to a given instance of an application. The Encoded Program Units and Boilerplate Objects/Images are common to all application users. Oracle9iAS Forms Services maps the shared components into physical memory, and then shares them between all processes accessing the same FMX file.

The first user to load a given FMX file will use the full memory requirement for that form. However, subsequent users will have a greatly reduced memory requirement, which is dependent only on the extent of local data. This method of mapping shared components reduces the average memory required per user for a given application.

Minimizing Network Usage

Bandwidth is a valuable resource, and the general growth of Internet computing puts an ever increasing strain on the infrastructure. Therefore, it is critical that applications use the network's capacity sparingly.

Oracle9iAS Forms Services communicates with the Java client using meta data messages. Meta data messages are a collection of name-value pairs that tell the client which object to act upon and how. By sending only parameters to generic objects on the Java client, there is approximately 90-percent less traffic (when compared to sending new code to achieve the same effect).

Oracle9iAS Forms Services intelligently condenses the data stream in three ways:

Maximizing the Efficiency of Packets Sent Over the Network

Latency can be the most significant factor that influences the responsiveness of an application. One of the best ways to reduce the effects of latency is to minimize the number of network packets sent during a conversation between the Java client and the Forms Server.

The extensive use of triggers within the Oracle9i Forms Developer model is a strength, but they can increase the effect of latency by requiring a network round trip for each trigger. One way to avoid the latency concerns adhering to triggers is by grouping them together through Event Bundling. For example, when a user navigates from item A to item B (such as when tabbing from one entry field to another), a range of pre- and post-triggers may fire, each of which requires processing on the Forms Server.

Event Bundling gathers all of the events triggered while navigating between the two objects, and delivers them as a single packet to Oracle9iAS Forms Services for processing. When navigation involves traversing many objects (such as when a mouse click is on a distant object), Event Bundling gathers all events from all of the objects that were traversed, and delivers the group to Oracle9iAS Forms Services as a single network message.

Rendering Application Displays Efficiently on the Client

All boilerplate objects in a given form are part of a Virtual Graphics System (VGS) tree. VGS is the graphical subcomponent that is common to all Oracle9i Forms Developer products. VGS tree objects are described using attributes such as coordinates, colors, line width, and font. When sending a VGS tree for an object to the Java client, the only attributes that are sent are those that differ from the defaults for the given object type.

Images are transmitted and stored as compressed JPEG images. This reduces both network overhead and client memory requirements.

Minimizing resources includes minimizing the memory overhead of the client and server processes. Optimal use of the network requires that bandwidth be kept to a minimum and that the number of packets used to communicate between the client and Oracle9iAS Forms Services be minimized in order to contain the latency effects of the network.

Tuning Oracle9iAS 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.

Issues discussed are:

Location of the Oracle9iAS Forms Services with Respect to the Data Server

The Forms Java client is only responsible to displaying the GUI objects. All of the Oracle9i Forms logic runs in Oracle9iAS 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 Oracle9iAS Forms Services. This allows Oracle9i Forms applications to run across slower networks, such as with modems or satellites.

The configuration in Figure 8-1, displays how the Oracle9iAS Forms Services and data server are co-located in a Data Center.

Figure 8-1 Co-Locating the Oracle9iAS Forms Services and Data Server

Text description of datactr-.gif follows

Text description of the illustration datactr-.gif

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 Oracle9i 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 Oracle9i 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:

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.

Oracle9iAS Forms Services provides the following pre-configured JAR files to support typical deployment scenarios.

Oracle JInitiator

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

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,

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 f90main.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 f90all.jar and f90all_jinit.jar, so they are only used if you use f90main.jar.

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

IE Native JVM

Since IE does not support JAR signing, you will need to use a CAB file. The following CAB file is provided for use with IE:

While is the only file provided for use with IE, it is significantly smaller than f90all.jar.

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

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:

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,

Using Caching

Both of the supported JVMs for Oracle9iAS 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.

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:

Other Techniques to Improve Performance

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

Go to previous page Go to next page
Copyright © 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Go To Product List
Solution Area
Go To Table Of Contents
Go To Index