|
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2) B14032-03 |
|
 Previous |
 Next |
|
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2) B14032-03 |
|
|
Previous |
Next |
The Oracle Application Server Forms Services and Java client include several optimizations that fit broadly into the following categories:
Section 10.1.5, "Minimizing Forms Services Resource Requirements"
Section 10.1.7, "Maximizing the Efficiency of Packets Sent Over the Network"
Section 10.1.8, "Rendering Application Displays Efficiently on the Client"
Use Oracle Enterprise Manager 10g Application Server Control Console to monitor Oracle Application Server Forms Services and review metrics information, including:
Forms Services Instances
Events
User Sessions
Forms Trace
Use the Overview page to monitor metrics for a Forms Services instance.
Start Enterprise Manager Application Server Control Console.
From the Enterprise Manager Application Server Control Console main page, select the link to the Forms Services instance that you want to monitor.
The Overview page for the Forms Services instance displays the following: Current Forms Services instance status (up, down)
URL of the Forms Services instance being monitored
Oracle Home of the Forms Services instance being monitored
Percent CPU usage for all forms runtime processes for this instance of Forms Services
Percent memory usage for all forms runtime processes for this instance of Forms Services
Number of users logged in
Response time is the ping time from Forms Enterprise Management agent to the forms servlet when the Enterprise Manager page is loaded.
Additionally, you can jump to the following detail pages: [[[to be linked]]]
Session Details
Forms Services Configuration
Environment
Forms Trace Configuration
Forms Utility
Use the Enterprise Manager Application Server Control Console to enable tracing for all events or specific ones.
Start the Enterprise Manager Application Server Control Console.
From the Enterprise Manager Application Server Control Console main page, select the link to the Forms Services instance that you want to monitor.
From the Overview page for the Forms Services instance, select the User Sessions link.
This page shows the following information about each user session for the Forms Services instance:
PID: The process ID of the user session.
CPU usage: The percent CPU used by the runtime process.
Memory usage: The percent memory used by the runtime process.
Client IP Address: The IP address of the client computer used to connect to Forms Services.
Database User Name: The database username used by the Forms application for the user session.
Time of connection: The time when the user connected to Forms Services.
Trace Status: Indicates if tracing is ON or OFF.
View Trace Log: Allows a user to view the trace log.
Configuration Section: Opens the Edit Section page for the configuration section used by a particular forms session.
Forms Runtime Pooling 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 situataions 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.
Use Enterprise Manager Application Server Control Console to configure runtime pooling for Forms Services with the following parameters as described in Table 10-1:
Table 10-1 Forms Runtime Pooling Parameters
| Parameter Name | Data type | Description | Default Value |
|---|---|---|---|
|
|
boolean |
Runtime pre starting or pooling is enabled only if true |
false |
|
|
integer |
Number of the runtime executables that should be spawned initially |
1 |
|
|
integer |
Time in minutes for which the pre started executables to exist |
0 (When set to zero the timer never starts) |
|
|
integer |
Minimum number of runtime executables to exist in the pool. |
0 |
|
|
integer |
The number of runtime executables to be created when below the minRuntimes. |
0 |
Note that prestartMin defines the minimum number of pre-started runtimes that must exist at any time 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 OC4J, the various values provided for the above parameters are on a per JVM basis, and not the total for the application.
An administrator has the capability to pre-start the specified number of executables for a particular application from the Enterprise Manager Application Server Control Console. The administrator selects the required application, which alerts Forms Services. The Forms Servlet will be loaded on the start of the Web server (OC4J).
During initialization of the Forms Servlet, the formsweb.cfg file is read and the server prestarts the applications which has the prestartRuntimes parameter enabled.
The Forms Utility page provides a simple user interface to call a set of operations on the middle tier. These features will be enhanced in future releases.
Presently, only ps (to obtain process information) and a number of arguments are available.
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 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.
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. 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.
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 Application Server 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).
Oracle Application Server 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 Application Server 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.
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 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 Oracle Application Server 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 Oracle Application Server Forms Services as a single network message.
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 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 Application Server Forms Services be minimized in order to contain the latency effects of the network.
