Built-in Optimization Features of Forms Services

Monitor Forms Services

Use Fusion Middleware Control to monitor Oracle Forms and review metrics information, including:

Forms Services Instances
Events
User Sessions
Forms Trace

Monitoring Forms Services Instances

Use the Forms Home page to monitor metrics for a Forms Services instance.

Start Enterprise Manager Fusion Middleware Control.
From the Enterprise Manager Fusion Middleware Control main page, select the link to the Forms Services instance that you want to monitor.
The Forms Home page for the Forms Services instance displays the following:
- Status of Forms application instance (up, down, unknown)
- URL of the Forms Services instance being monitored
- Number of Forms sessions
Additionally, you can navigate to the following detail pages:
- Performance Summary
- Servlet Logs
- Session Details
- Web Configuration
- Environment Configuration
- Trace Configuration
- User Sessions
- JVM Configuration
- JVM Controllers
  
  In the Performance Summary page, you can add charts for other Forms metrics to the page dynamically by using the Show Metric Palette. You can also overlay metrics to compare them. For example, drag and drop Private Memory consumed by two JVM Controllers into one chart to compare them, see Monitoring in Tuning Performance.

Monitoring Forms Events

Use the Enterprise Manager Fusion Middleware Control to enable tracing for all events or specific ones. The follows table provides the list of tasks you can perform on this page.

Table -49 Tasks for Monitoring Forms Events

Task	See
Monitoring metrics for user sessions	To view Forms user sessions:
Sorting metrics information	To sort the list of Forms user sessions:
Searching for metrics information	To search for a Forms user sessions:

Forms Services Web Runtime Pooling

Forms Runtime Pooling (or Forms Runtime prestart) enables the startup of a configurable number of application runtime engines prior to their usage. Runtime Pooling provides quick connections at server peak times, which shortens the server-side application startup time. Runtime pooling is useful for situations where server configurations have a small window in which many users connect to a Forms application. All prestarted runtime engines run in the same environment serving the same application.

Configuring Prestart Parameters

Use Enterprise Manager Fusion Middleware Control to configure runtime pooling for Forms Services with the following parameters, as described in the following table.

Table -50 Forms Runtime Pooling Parameters

Parameter Name	Data type	Description	Default Value
`prestartRuntimes`	boolean	Runtime pre starting or pooling is enabled only if true	false
`prestartInit`	integer	Number of the runtime processes that should be spawned initially	1
`prestartTimeout`	integer	Time in minutes after which all the prestarted processes of this pool (configuration section) will be stopped. A runtime process is removed from the prestart pool once client connection is made and thus will not be stopped.	0 (When set to zero the timer never starts)
`prestartMin`	integer	Minimum number of runtime processes to exist in the pool.	0
`prestartIncrement`	integer	The number of runtime processes to be created when the number of prestarted runtime processes is less than minRuntimes.	0

Note:

See that prestartMin defines the minimum number of pre-started runtimes that must exist at any time while runtime pooling is still active for a specific application. The minimum value must be less than or equal to what's defined for the prestartInit parameter. The prestartMin parameter can be modified at any time and does not require the application server to be restarted. The new entries will be picked up when a client requests a connection to a pre-started runtime process and the prestarted runtime processes have not timed out. Once they have timed out, an application uses default behavior and a minimum threshold is not maintained.

Each configuration section can specify values for these parameter. If the prestartRuntimes = true entry is found, but there is no associating prestart parameter, then default values are used.

In a load balanced system that has multiple instances of Oracle WebLogic Managed Server, the various values provided for the above parameters are on a per JVM basis, and not the total for the application.

Starting Runtime Pooling

An Administrator can configure specific application(s), from the Enterprise Manager Fusion Middleware Control, to enable Runtime Pooling. On the startup of the application server (Oracle WebLogic Managed Server), the configured number of Forms Runtime processes are pre-started for each application.

In the initialization phase of the Forms servlet, the configuration file (formsweb.cfg) is read and the server pre-starts the applications which have the prestartRuntimes parameter enabled.

Scheduling Runtime Pooling

Scheduling Runtime Pooling (or Scheduling Runtime Prestart) is a feature that enables you to schedule the prestart of Forms Runtime engines. In addition to managing the startup of a configurable number of Forms Runtime engines prior to their usage, Oracle Forms now allows you to schedule the prestarting of Forms Runtime processes on a more flexible basis, at any appropriate time. You can schedule a Forms Runtime prestart, view existing schedules, delete any existing schedule, and export and import a schedule using the Enterprise Manager Fusion Middleware Control.

Setting the prestartRuntimes Parameter

The parameter, prestartRuntimes, must be set to TRUE for the configuration section that will use pre-started processes. If this parameter is not correctly set, attempts to create a schedule will fail silently, even though the message, Prestart job has been created, is displayed.

prestartRuntimes must be set in the Forms Web Configuration. It is recommended not setting the parameter in the [default] section. Doing so will result in processes being started for all other configurations unless overridden with a value of FALSE for configuration sections where this is not desired.

Creating a Prestart Schedule

To create a prestart schedule, perform the following steps:

From the Forms Menu, select Schedule Prestart.

The Schedule Prestart page is displayed.
From the Scheduled Jobs region, click Create. The Create Job page is displayed for scheduling a prestart.

Figure -49 Scheduling Forms Runtime Prestart

Description of "Figure -49 Scheduling Forms Runtime Prestart"
In Job Name, enter a name for the schedule.

Maximum length of the job name must not exceed 100 characters. The name must not contain any special characters such as ampersand (&).
From the Configuration Section list, choose a configuration type.

This list contains a logical set of parameters.
In Prestart Init, enter a numerical value for the number of runtime processes that must be spawned initially. Ensure that the value is greater than or equal to 1.
In Prestart Timeout, enter a numerical value for the time in minutes after which the unused prestart process will be stopped. If this value is set to zero, the timer never starts and thus the processes do not time out.
From the Schedule Type options, select the appropriate schedule type.

Following are the three types of schedules that you can set:
- One Time(Delay based): Select this option if you want to schedule a single occurrence prestart based on the initial delay. Initial delay is a time based parameter that specifies the number of hours or minutes after which the prestart will begin. If you select this option, you must enter the initial delay time (in hours or minutes) in the Initial delay field that appears below the schedule type.
- One Time(Date based): Select this option if you want to schedule a single occurrence prestart based on a date. If you select this option, you must enter the date and time in the Start Date field that appears below the Schedule type.
- Repeating: Select this option if you want to schedule a repeat prestart. From the Frequency list, you can select one of the following options:
  - Repeat date and interval: If you select this option, you must specify the start date and interval after which you want the prestart to repeat.
  - Repeat initial delay and interval: If you select this option, you must specify the initial delay and interval after which you want the prestart to repeat.
Click Submit.

You can click Show Jobs to view all the prestart schedules that are created.

Deleting a Prestart Schedule

To delete a prestart schedule, perform the following steps:

From the Forms Menu, select Schedule Prestart. The Schedule Prestart page is displayed.
From the Scheduled Jobs region, select the row of the scheduled prestart that you want to delete.

Figure -50 Deleting a Prestart Schedule

Description of "Figure -50 Deleting a Prestart Schedule"

Tip:
You can select multiple rows to delete at the same time.
Click Delete. The selected prestart schedule is deleted.

Exporting and Importing Prestart Schedules

This utility allows you to export all existing schedules from a particular managed server and import it to some other managed server. This feature does not allow the users to export schedules selectively; the user must export all existing schedules. To export and import prestart schedules, perform the following steps:

From the Forms Menu, select Schedule Prestart. The Schedule Prestart page is displayed.
From the Scheduled Jobs region, click Export. A dialog box appears.
Enter a new file name in the dialog box.

Note:
The file name must contain .xml extension.
Click OK. This will create an XML file that contains the attributes of all prestart schedules. Depending on your browser settings, you will either be prompted to choose a location to save the file in, or the file will be saved at a default location on you local machine.
To import the schedules (that you have exported in the above steps) to some other managed server, go to the Schedule Prestart page of that server, and click Import. A dialog box appears.
Enter the name of the file that you created while exporting the schedules. You can also click Browse on the dialog box and upload the xml file from you local machine.
Click OK.

Note:
If there is an error in any schedule entry in the xml file, the server skips that particular schedule and imports the next schedule entry. If there are any expired schedules in the xml file, they are ignored and not imported.

The imported schedules will now be listed in the Scheduled Jobs region.

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 Oracle 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 classes 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 Oracle 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:

Encoded Program Units
Boilerplate Objects/Images
Data Segments

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. Oracle 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.

Oracle Forms Services communicates with the Java client using metadata messages. Metadata 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).

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

When sets of similar messages (collections of name-value pairs) are sent, the second and subsequent messages include only the differences from the previous message. This results in significant reductions in network traffic. This process is called message diff-ing.
When the same string is to be repeated on the client display (for example, when displaying multiple rows of data with the same company name), Oracle Forms Services sends the string only once, and then references the string in subsequent messages. Passing strings by reference increases bandwidth efficiency.
Data types are transmitted in the lowest number of bytes required for their value.

Maximizing the Efficiency of Packets Sent Over the Network

The extensive use of triggers within the Oracle Forms Developer model is a strength, but they can increase the effect of latency by requiring a network round trip for each trigger. Latency can be the most significant factor that influences the responsiveness of an application. Notice that latency is not the same as network speed. Network speed involves a measure of the bits that can be transported per time unit whereas latency is the time taken for one bit to travel from one end-point to the other. 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 Services.

Oracle Forms Services implements event bundling by grouping trigger events together through Event Bundling. Event Bundling gathers all of the events triggered while navigating between the two objects, and delivers them as a single packet to Oracle Forms Services for processing.

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 Services. 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 Oracle Forms Services as a single network message.

Applet/servlet parameters like gzipCompressApplet and removeCommentLinesFromApplet and others can help in improving startup performance. Refer to Web Configuration Parameters for details on these and many other useful parameters.

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 Oracle 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 Oracle Forms Services be minimized to contain the latency effects of the network.