Skip Headers
Oracle® Fusion Middleware Performance and Tuning Guide
11g Release 1 (11.1.1)

Part Number E10108-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

17 Oracle Adapters Performance Tuning

This chapter describes how to tune Oracle Adapters for optimal performance. Oracle Adapters, a component of the Oracle SOA Suite of Applications, provide an integrated view of data and allow multiple applications to be integrated.

This chapter contains the following sections:

17.1 About Oracle Adapters

Oracle technology adapters integrate Oracle Application Server and Oracle Fusion Middleware components such as Oracle BPEL Process Manager (Oracle BPEL PM) or Oracle Mediator components to file systems, FTP servers, database queues (advanced queues, or AQ), Java Message Services (JMS), database tables, and message queues (MQ Series).

For more information on Oracle Adapters, see Oracle Fusion Middleware User's Guide for Technology Adapters.

17.2 Oracle JCA Adapters for Files/FTP

This section describes the various features available for scalability and performance tuning of Oracle File and FTP Adapters.The Oracle File and FTP Adapters provide knobs to throttle the inbound and outbound operations. The Oracle File and FTP Adapters also provide knobs that can be used to tune the performance of outbound operations. The Oracle File and FTP Adapters knobs are described in the following sections:

Note:

For composites with Oracle File and FTP Adapters, which are designed to consume very large number of concurrent messages, you must set the number of open files parameter for your operating system to a larger value. For example, to set the number of open files parameter to 8192 for Linux, use the ulimit -n 8192 command

17.2.1 Inbound Throttling Best Practices

The Oracle File and FTP Adapters provide parameters that can be used to throttle the inbound operations. The table below describes the inbound throttling practices:

Parameter Type Values Description

MaxRaiseSize

JCA

<property name="MaxRaiseSize" value="100"/>

Default: 10000 (ten thousand)

This parameter defines the maximum number of files that the inbound adapter would submit for processing on each polling cycle. For example, if your inbound directory has 1000 files and the MaxRaiseSize is set to 100, the adapter can increase to 100 files on each polling cycle.

Defined in the Inbound JCA File.

SingleThreadModel

JCA

<property name="SingleThreadModel" value="true"/>

Default: False (In this case, the global in-memory queue is used).

If the value is true, the poller lists, translates, or publishes files in the same thread. In other words, it does not use the global in-memory queue for publishing.

Defined in the Inbound JCA File.

ThreadCount

JCA

<property name="ThreadCount" value="10"/>

Default: -1 (In this case, the adapter uses the global thread pool and in-memory queue)

This parameter enables the Oracle File and FTP Adapters to create their own processor threads rather than depending on the global pool of processor worker threads for processing the enqueued files. This parameter partitions the in-memory queue and each composite application receives its own in-memory queue.

If the ThreadCount is set to 0, then the threading behavior is the same as that of the SingleThreadModel. If the ThreadCount is set to -1, then the global thread pool is activated, which is the same as the Default Threading Model. The maximum value that can be set for ThreadCount is 40.

Defined in the Inbound JCA File.


17.2.2 Outbound Throttling Best Practices

The Oracle File and FTP Adapters provide parameters that can be used to throttle the outbound operations. The table below describes the outbound throttling practices:

Parameter Type Value Description

ConcurrentThreshold

JCA

<property name="ConcurrentThreshold" value="100"/>

Default: 20 (In this case, not more than 20 translations occur for a particular outbound scenario.)

This parameter specifies the maximum number of translation activities that are allowed to start in parallel for a particular outbound scenario. The translation step during the outbound operation is CPU intensive and must be monitored as it might cause other applications or threads to starve. The maximum value is 100.

Defined in the Outbound JCA File.


17.2.3 Outbound Performance Best Practices

The Oracle File and FTP Adapters provide parameters that can be used to tune the performance of outbound operations. The table below describes the outbound performance parameters:

Parameter Type Value Description

UseStaging

JCA

<property name="UseStaging" value="true"/>

Default: True

If the parameter is set to true, then the outbound Oracle File or FTP Adapter writes translated data to a staging file and later streams the staging file to the target file. If the parameter is set to false, then the outbound Oracle File or FTP Adapter does not use an intermediate staging file.

Defined in Outbound JCA File.

serializeTranslation

Endpoint Property

<reference name="PurchaseOrderOut"> <interface.wsdl interface="...."/> <binding.jca config="PurchaseOrderOut_ftp.jca"/> <property name="serializeTranslation" type="xs:string" many="false" source="" override="may">true</property> </reference>

Defaults:

  • True (If the value of UseStaging is set to True)

  • False (If the value of UseStaging is set to False)

If True, then the translation step is serialized using a semaphore. The number of permits for semaphore (monitoring the translation step) comes from ConcurrentThreshold parameter (listed in the preceding table). The default value of True is used because the translation step is CPU intensive and you do not want to starve other applications or threads.

If False, then the translation step occurs outside the semaphore.

Defined in Binding property for reference in composite.xml.

inMemoryTranslation

Binding Property

<reference name="PurchaseOrderOut"> <interface.wsdl interface="...."/> <binding.jca config="PurchaseOrderOut_ftp.jca"/> <property name="inMemoryTranslation" type="xs:string" many="false" source=""override="may">false</property> </reference>

Default: False

This parameter is applicable only if UseStaging is False.

If True, then the translation step occurs in-memory (an in-memory byte array is created.)

If False, then the adapter creates an output stream to the target file (FTP, FTPS, and SFTP included) and allows the translator to translate and write directly to the stream.

Defined in Binding property for reference in composite.xml.


17.3 Oracle JCA Adapter for Database Tuning

The Oracle Database Adapter is pre-configured with many performance optimizations. You can, however, make some changes to reduce the number of round trips to the database, as described in the following sections:

Note:

The tuning considerations in this chapter are listed for example only. Tuning parameters are specific to each deployment. Review you current usage and performance issues to determine which tuning considerations can improve performance.

17.3.1 JCA Adapter Basic Tuning Considerations

Adapter performance is directly related to the number of round-trips to the database, and the network cost of each trip. If performance becomes an issue, and making modifications is appropriate for your deployment, consider tuning the following parameters:

  • Use Indexes

    Indexes can improve performance of selects, updates and deletes. Index all queried fields, such as the primary key and the MarkReadField of the LogicalDeletePollingStrategy, when polling. For MarkReadField specify a non-null MarkUnreadValue. Caution: An index on a column containing many nulls may revert to full table scans.

  • Disable OptimizeMerge

    The OptimizeMerge parameter allows the detection of XML elements for which no value was specified. The related columns are excluded from inserts and updates. Disabling this parameter generally improves performance, but there is one case where it could have a negative effect. If multiple rows are being passed in as a single XML, and each row has different columns set (user entered with many optional fields), there is no benefit from batch writing, as each insert or update is different.

  • Increase MaxRaiseSize

    The MaxRaiseSize parameter indicates the maximum number of XML records that can be raised at a time to the BPEL engine. For example, if you set MaxRaiseSize = 10, then 10 database records are raised simultaneously. On an inbound read, for example, you can set MaxRaiseSize = 0 (unbounded) which means that if you read 1000 rows, you can create one XML with 1000 elements. These elements are passed through a single Oracle BPEL Process Manager instance. A merge on the outbound side can then take all 1000 in one group and write them all at once with batch writing. Use the MaxRaiseSize parameter for publishing large payloads.

  • Increase MaxTransactionSize

    This property controls the number of records processed per transaction by each thread. If set to a large value such as 1000, turning on the UseBatchDestroy option could have a negative impact on performance. Setting a large MaxTransactionSize and a small MaxRaiseSize could also have negative impact on performance. Consider maintaining up to a 10:1 ratio in a synchronous scenario. Ideally, you should consider increasing MaxRaiseSize until it is a 1:1 ratio.

  • Enable UseBatchDestroy

    This property controls how the processed records are updated (ex: Deleted for DeletePollingStrategy, MarkedProcessed for LogicalDeleteStrategy). If set, only one update/delete is executed for all the rows that are part of that transaction. The number of rows in a transaction is controlled by the MaxTransactionSize option. Note that this may not always offer an improvement because, by default, batch writing is used, which also ends up in a single round trip to the database.

  • Enable Batch Reading

    Batch reading of one-to-many and one-to-one relationships is on by default. You can also use joined reading for one-to-one relationships instead, which may offer a slight improvement.

  • Disable Delete Polling Strategy

    Avoid the delete polling strategy because it must individually delete each row. The sequencing polling strategy can destroy 1000 rows with a single update to a helper table. Note that a LogicalDelete is also better than Delete, as updates are typically faster than deletes. To maintain performance, however, ensure that you have indexed the table. If you have not indexed, you can keep the total number of rows small by using deletes. In some instances deletes may be faster as the cost of a full table scan is negligible.

  • Use Distributed Polling

    Distributed polling enables you to configure polling for scalability. For more information, see "Scalability" in Oracle Fusion Middleware User's Guide for Technology Adapters.

  • Use Synchronous Processes

    On BPEL you can configure Database Adapter processes to be synchronous. You can also create sequential routing rules in Mediator. This can improve throughput in database-to-database scenarios, as there is less instance processing impact.

  • Use Insert

    The insert operation is the most performant because it uses no existence check and has no extra performance impact associated with it. There are no reads, only writes. If you know that you are inserting most of the time, use insert, and catch a unique key constraint SQL exception inside your BPEL process, which can then perform a merge or update instead. To monitor performance, you can enable debug logging and then watch the SQL for various inputs.

  • Disable Merge

    Merge executes one extra SELECT per related table. The SELECT is used to determine whether each row should be inserted or updated. If the row is updated, the update performed is minimal. If no rows have changed, nothing is updated.

  • Use Connection Pooling

    The adapter should also point to a tuned data source connection pool. Tuning the connection pool is important because creating and tearing down database connections can impact performance.

  • Use Attribute Filtering

    On the Attribute Filtering page of the Adapter Configuration Wizard you can choose which fields to map to the XML and vice versa. You can improve performance by deselecting columns that are not needed for your particular business case, especially large columns like LOBs.

  • Use Native Sequencing

    If you are using the XSL functions to assign primary keys to records, consider using the built-in native sequencing support in the adapter. Sequencing support obtains and caches 50 keys at a time by default. Caching improves performance by reducing the number of round trips. The chunk size can be controlled incrementally by modifying the sequencePreallocationSize connector property.

  • Do not use primary or foreign keys on the database

    Using primary and foreign keys can impact performance. Avoid using them when possible.

  • JDBC Driver Class

    The default JDBC driver class used to create the physical database connections in the connection pool is oracle.jdbc.xa.client.OracleXADataSource. Changing the driver to oracle.jdbc.OracleDriver may provide some performance improvement.

    For more information on tuning the JDBC drivers, see "Third Party JDBC Driver and Database Connection Configuration" in Oracle Fusion Middleware User's Guide for Technology Adapters.

17.3.2 Existence Checking

One method of performance optimization for merge is to eliminate check database existence checking. The existence check is marginally better if the row is new, because only the primary key is returned, not the entire row. Due to the nature of merge, however, if the existence check passes, the entire row must be read to calculate what changed. Therefore, for every row to be updated, you see one extra round trip to the database during merge.Use check cache on the root descriptor/table and any child tables if A is master and B is a privately owned child. If A does not exist, B cannot exist. And if A exists, all of its child tables are loaded as part of reading A.

Note:

One way to prevent merge from performing an existence check for every record, when you know that an insert is required, is to set the primary key to null.

17.3.3 Throttling

It is possible to configure a speed limit on DbAdapter performance to protect down-stream components from message bursts. Consider leaving burst records unprocessed on the source database until SOA can process them efficiently. As of Oracle Adapters release 11.1.1.6.0 you can set the inbound DbAdapter property RowsPerPollingInterval. It acts as a limit on the number of records which can be processed in one polling interval. The default is unlimited.

The following sections describe the configuration options for RowsPerPollingInterval:

17.3.3.1 Formula

The formula for maximum rows per second is:

Number of active nodes in SOA cluster x NumberOfThreads x RowsPerPollingInterval / PollingInterval

17.3.3.2 RowsPerPollingInterval and MaxTransactionSize

MaxTransactionSize can be thought of as RowsPerDatabaseTransaction or DatabaseFetchSize. It does not affect how many rows can be processed in one polling interval period.

The one exception is the following configuration:

-distributed polling checked, usesSkipLocking="false"

In this one case RowsPerPollingInterval will default to MaxTransactionSize instead of unlimited.

If RowsPerPollingInterval is set to lower than MaxTransactionSize or MaxRaiseSize, they will be effectively lowered to RowsPerPollingInterval.

17.3.3.3 Configuration

There is no UI support for RowsPerPollingInterval. Instead find the db.jca file for the inbound polling service and add the property manually. Add it to the same section as the properties MaxRaiseSize, MaxTransactionSize, and PollingInterval, in any order.

17.4 Oracle Socket Adapter Tuning

This section describes performance tuning for Oracle Socket Adapter. Performance can be optimized for the Oracle Socket Adapter using Connection Pool if the socket server you are connecting to does not close the socket with each interaction. Connection pool lets you use a socket connection repeatedly, avoiding the overload of creating a new socket for each interaction.

Note:

The Connection Pool feature is applicable to outbound interactions only. For more information on Socket Adapters, see "Oracle JCA Adapter for Sockets" in Oracle Fusion Middleware User's Guide for Technology Adapters

In order to enable the connection pool feature for the Oracle Socket Adapter, the KeepAlive connection factory property must be set to True. This connection property can be modified using the Connection Pool tab of Oracle WebLogic Server Administration Console.

For instructions on modifying the Oracle Socket Adapter connection pooling, see "Configuring Oracle Socket Adapter Connection Pooling" in Oracle Fusion Middleware User's Guide for Technology Adapters.

17.5 Oracle SOA JMS Adapter Tuning

This section describes some of the properties that can be set for the Oracle SOA JMS Adapter to optimize performance. See "Introduction to the Oracle JMS Adapter" in the Oracle Fusion Middleware User's Guide for Technology Adapters for more information.

17.5.1 adapter.jms.receive.threads Property

To improve performance, the adapter.jms.receive.threads property can be tuned for an adapter service. The default value is 1, but multiple inbound threads can be used to improve performance. When specified, the value of adapter.jms.receive.threads is used to spawn multiple inbound poller threads.

For example:

<service name="dequeue" ui:wsdlLocation="dequeue.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/jms/textmessageusingqueues/textmessageusingqueues/dequeue%2F#wsdl.interface(Consume_Message_ptt)"/>
<binding.jca config="dequeue_jms.jca">
<property name="adapter.jms.receive.threads" type="xs:string" many="false">10</property>
</binding.jca">
</service>

17.6 Oracle AQ Adapter Tuning

This section describes Oracle AQ Adapter tuning configurations.

17.6.1 adapter.aq.dequeue.threads Property

To improve dequeue performance 'adapter.aq.dequeue.threads' property can be set for an adapter service. Default value is 1 but multiple inbound threads can be used to improve performance. The value of property 'adapter.aq.dequeue.threads' is used to spawn multiple inbound poller threads.

For example:

<service name="dequeue" ui:wsdlLocation="dequeue.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/aq/raw/raw/dequeue/#wsdl.interface(Dequeue_ptt)"/>
<binding.jca config="dequeue_aq.jca">
<property name="adapter.aq.dequeue.threads" type="xs:string" many="false">10</property>
</binding.jca>
</service>

17.7 Oracle MQ Adapter Tuning

The Oracle MQ Series Adapter supports the scalability feature for inbound operations only. Oracle MQ Series Adapter provides the parameter to control the number of threads that dequeue the messages from the inbound queue.You must specify the following property in the.jca file:

InboundThreadCount='N'

In the example above N is the number of threads that you want to span to dequeue the messages from the inbound queue.