Performance issues with SOA console
The typical troubleshooting scenario we like to get as much information as we can. However, we have to balance that with the cost of collecting the information. For example, in a large SOA installation with several hindered or perhaps millions of composite instances, setting the console to track the ‘state’ of those instances is abusive and time consuming. One should only enable the composite instance state monitoring in the SOA console if that information is actually more valuable than the delay in getting the information. Collecting this and other ‘optional’ information can bring the OEM console to its knees.
The guidance: Only collect the information that you are currently and actively using
Option: use a different channel to collect the same information. Perhaps a separate query directly to the database will reveal the desired information without crushing the console’s responsiveness.
Capture Composite Instance State
|
Select to capture the SOA composite application instance state. Enabling this option may result in additional run time overhead during instance processing. This option provides for separate tracking of the running instances. All instances are captured as either running or not running. This information displays later in the State column of the composite instances tables for the SOA Infrastructure and SOA composite application, where:
Valid states are running, completed, faulted, recovery needed, stale, terminated, suspended, and state not available. The running and completed states are captured only if this check box is selected. Otherwise, the state is set to unknown. The conditional capturing of these states is done mainly to reduce the performance overhead on SOA Infrastructure run time. Note: If this property is disabled and you create a new instance of a SOA composite application, a new instance is created, but the instance does not display as running, faulted, stale, suspended, terminated, completed, or requiring recovery in the table of the Dashboard page of the composite application. This is because capturing the composite state of instances is a performance-intensive process. For example, if you enable this property and create an instance of a SOA composite application in the Test Web Service page, a new instance appears in the Dashboard page of the composite application. If you click Show Only Running Instances in the Dashboard page, the instance displays as running. If you then disable this property and create another instance of the same composite application, a new, running instance is created. However, if you then select Show Only Running Instances, the new instance is not listed in the table of running instances. In addition, to terminate a running instance, the instance must have a state (for example, running, faulted, suspended). This activates the Abort button on the Instances page of a SOA composite application. If this check box is not enabled before creating an instance, the Abort button is inactive, and you cannot terminate the instance. |
Also note the very explicit (and counter-intuitive) warnings about how the console displays the state information (highlighted in bold/red)
Reference:
http://download.oracle.com/docs/cd/E12839_01/integration.1111/e10226/soainfra_config.htm#BHCHBAIA













