Oracle performance

Troubleshooting

The first step to interpreting the results is to find the cause for failed user sessions, if any. You should examine the error log file to find corresponding error information. Most of the time failures are the result of differences in execution flow during creation of the script and play back. For instance, during playback a message dialog pops up that did not pop up during script creation. Parameterization can change the execution flow of the Forms application or module version and data differences. Often repeated transactions cause errors (see: defining a transaction) These type of errors will often result in the following generic error log entry:

Forms session <X> aborted: unable to communicate with runtime process

For error determination you can among others examine the inbound files for the failed user sessions to trace the application flow during the test. An inbound file contains all inbound network traffic for a specific user session. You can easily relate a user session to its corresponding inbound file by its file name. The file name contains the session identifier. From the network traffic, although partly binary, you can deduce the execution flow. Note that inbound files are only available in the output directory when the support logging is set in the configuration tab.

Another common error log entry is:

The Forms runtime failed to respond!

When the forms engine does not respond within the recorded response time plus 60 seconds (default threshold) Forms2test will fail and abort the running user session and log the error. This error may for instance occur when the user session waits for a lock or when the web server cannot handle all requests concurrently and puts requests to the backlog queue.

Tip: When the web server cannot handle all incoming requests concurrently it will put requests to the backlog. This situation will always have a negative affect on performance. You should consider setting the maximum number of requests the web server can handle to at least 1.1 times the expected number of end users. See MaxClients (Unix/Linux) or ThreadsPerChild (Windows).

The next error is directly related to the Operating System configuration of the computer running Forms2test.

Address already in use

The default number of sockets available to Forms2test is too restrictive. Forms2test requires a lot of ephemeral ports when simulating a great number of users. See Preparing to use Forms2test for the software requirements and how to extend the port range.

The following error will most likely happen when the middle tier Operating System is Windows.

Forms session <X> failed during startup: no response from runtime

The error is occurring because Windows has exceeded the capacity of the operating systems Non-IO Desktop heap resource. Increase the size of the Non-IO Desktop heap by increasing the value in the Registry: Go to key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems and increase the third SharedSection parameter from 512 (default) to 3072. Reboot for the new values to take effect (see Metalink Note 207706.1)

Often you can relate failed sessions to server statistics. In the following three graphs for instance you see a correlation between swapping (memory shortage) of the application server and the latency delay and number of failed user sessions. The following errors where written to the error log:

• session <X> aborted: unable to communicate with runtime process
• The Forms runtime failed to respond

NMON report of Oracle Forms server





The Oracle Forms environment appears to be very sensitive for physical memory shortage. As a rule of thumb you need about 12 MB of memory per runtime. Note that a user session is not the same as an end user. Often an end user has more than one browser session opened.