This chapter describes tuning configurations that can apply to multiple SOA Suite applications.
For more information on any of the SOA Suite Applications, see Section 10.4.1, "SOA Suite Components" for a list of the application-specific documentation provided in this guide.
Note:
Additional SOA tuning recommendations can be found in "Managing Large Documents and Large Number of Instances" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Refer to the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite for more information on configuring the SOA Applications.
SOA Infrastructure configuration parameters impact the entire SOA Infrastructure. The following configurations are modified through the SOA-INFRA component:
Viewing and setting the SOA Infrastructure audit level
Capturing the state of the SOA composite application instance
Enabling the payload validation of incoming messages
Specifying the callback server and server URLs
Setting UDDI registry properties
Viewing the data source JNDI locations
Setting the non-fatal connection retry count
Setting Web service binding properties
For more information on SOA configuration, see "Configuring SOA Infrastructure Properties" in Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
The Audit Level property enables you to select the level of information to be collected by the message tracking infrastructure. This information is collected in the instance data store (database) associated with the SOA Infrastructure. This setting has no impact on what is written to log files.
| Value | Description |
|---|---|
|
Off |
No composite instance tracking and payload tracking information is collected. No logging is performed. Note that no logging and display of instances in Oracle Enterprise Manager Fusion Middleware Control Console can result in a slight performance increase for processing instances. Instances are created, but are not displayed. |
|
Production |
Composite instance tracking is collected, but the Oracle Mediator service engine does not collect payload details and the process service engine does not collect payload details for assign activities (payload details for other activities are collected). This level is optimal for most normal production operations. |
|
Development |
Enables both composite instance tracking and payload detail tracking. However, this setting may impact performance. This level is useful largely for testing and debugging purposes. |
You can use the CompositeInstanceStateEnabled property to configure the SOA composite application instance state. Note, however, that enabling this option may impact performance during instance processing. This option enables 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. The valid states are running, completed, faulted, recovery needed, stale, terminated, suspended, and state not available.
This parameter is used to limit the audit trail size while it is being built. The default value is 1MB. If the audit trail exceeds the instanceTrackingAuditTrailThreshold size (1MB by default), then an exception is thrown, and the audit trail is not fully built. The value is in Bytes, so the default value is 1024*1024. This parameter can improve performance, as it prevents huge audit trails to potentially consume a lot or all the memory available on the SOA server where the audit trail is built. So in many way it acts as a safety valve. However in some cases users might want to increase the default value, if they get an exception while retrieving audit trails from Enterprise Manager, that states the " instanceTrackingAuditTrailThreshold" has been exceeded.
The default logging level is "NOTIFICATION". For stress testing and production environments, consider using the lowest acceptable logging level, such as "ERROR" or "WARNING" whenever possible.
For more information on setting the logging levels for your applications, see "Configuring Log File" in Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
SOA soa-infra level configurations can be set through Oracle Enterprise Manager.
For more information, see "Getting Started with Administering Oracle SOA Suite and Oracle BPM Suite" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
JVM parameters can have an impact on SOA performance. The major factors that impact a SOA component's performance relate to the heap size. For more information on tuning the JVM for performance, see Section 2.4, "Tuning Java Virtual Machines (JVMs)".
Tuning your database configurations may be useful with the SOA Suite of applications. Configurations and specific settings may vary for different use cases. See your database-specific administration manuals for more information on tuning database properties.
For additional basic database tuning guidelines, see Section 2.6, "Tuning Database Parameters".
SOA obtains database connections using an application server managed data source. You can use the WebLogic Server Console to configure SOA data source. For more information on using the WebLogic Server Console, seethe Oracle Fusion Middleware Administrator's Guide.
Consider the following data source configurations when performance is an issue:
When configuring the data source, ensure that the connection pool has enough free connections.
Statement caching can eliminate potential performance impacts caused by repeated cursor creation and repeated statement parsing and creation. Statement caching also reduces the performance impact of communication between the application server and the database server
Disable unnecessary connection testing and profiling.
For more information, see "Tuning JDBC Stores" in Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server.
Consider using hash partitioning on your tables and indexes if your data does not easily lend itself to range partitioning, but you would like to partition for performance and manageability reasons. Hash partitioning provides a method of evenly distributing data across a specified number of partitions. Rows are mapped into partitions based on a hash value of the partitioning key. Creating and using hash partitions gives you a highly tunable method of data placement, because you can influence availability and performance by spreading these evenly sized partitions across I/O devices (striping).
To improve performance, consider using hash partitioning on the following tables and indexes:
| Partitioned Table Name | Partition Type | Number |
|---|---|---|
|
AUDIT_COUNTER |
Hash partitioning of AC_PK index |
Not Applicable |
|
CUBE_INSTANCE |
Partitioned and Reverse key index CI_CREATION_DATE |
Not Applicable |
|
CUBE_SCOPE |
Partition by hash (CIKEY) |
Partitions = 200 |
|
MEDIATOR_CASE_INSTANCE |
Partition by hash ("ID") |
Partitions = 200 |
|
XML_DOCUMENT |
Partition by hash (document_id) |
Partitions = 200 |
| Hash Partitioned Indexes |
|---|
|
COMPOSITE_INSTANCE_CREATED |
|
BRDECISIONINSTANCE_INDX3 |
|
MEDIATOR_INSTANCE_INDEX2 |
|
MEDIATOR_INSTANCE_INDEX5 |
|
MEDIATOR_INSTANCE_INDEX6 |
|
MEDIATOR_INSTANCE_INDEX1 |
|
MEDIATOR_INSTANCE_INDEX3 |
|
MEDIATOR_CASE_INSTANCE_INDEX2 |
|
MEDIATOR_CASE_DETAIL_INDEX1 |
|
REFERENCE_INSTANCE_CO_ID |
|
CI_NAME_REV_STATE |
|
DOC_DLV_MSG_GUID_INDEX |
|
STATE_TYPE_DATE |
For optimum performance, you must ensure that the WebLogic For complete performance tuning of Weblogic Server, refer to Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server.