Thursday, August 23, 2012

Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL: Significant Tips

Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL: Significant Tips 


OneWayDeliveryPolicy

The oneWayDeliveryPolicy is from the Oracle 10g configuration property deliveryPersistencePolicy.
The new configuration property name is bpel.config.oneWayDeliveryPolicy.

The oneWayDeliveryPolicy property controls database persistence of messages entering Oracle BPEL Server. By default, incoming requests are saved in the delivery service database tabledlv_message. These requests are later acquired by Oracle BPEL Server worker threads and delivered to the targeted BPEL process. This property persists delivery messages and is applicable to durable processes.
When setting the oneWayDeliveryPolicy property to async.cache, if the rate at which one-way messages arrive is much higher than the rate at which Oracle BPEL Server delivers them, or if the server fails, messages may be lost. In addition, the system can become overloaded (messages become backlogged in the scheduled queue) and you may receive out-of-memory errors. Consult your own use case scenarios to determine if this setting is appropriate.
One-way invocation messages are stored in the delivery cache until delivered. If the rate at which one-way messages arrive is much higher than the rate at which Oracle BPEL Server delivers them, or if the server fails, messages may be lost.
ValueDescription
async.persist (Default)Delivery messages are persisted in the database. With this setting, reliability is obtained with some performance impact on the database. In some cases, overall system performance can be impacted.
async.cacheIncoming delivery messages are kept only in the in-memory cache. If performance is preferred over reliability, this setting should be considered.
syncDirects Oracle BPEL Server to bypass the scheduling of messages in the invoke queue, and invokes the BPEL instance synchronously. In some cases this setting can improve database performance.




MaximumNumberOfInvokeMessagesInCache

This property specifies the number of invoke messages that can be kept in the in-memory cache. Once the engine hits this limit, it would push the message to dispacther in-memory cache, instead it would save the message in the db and these saved messages can be recovered using recovery job. You can use value -1 to disable.
The default value is 100000 messages.



StatsLastN

The StatsLastN property sets the size of the most-recently processed request list. After each request is finished, statistics for the request are kept in a request list. A value less than or equal to 0 disables statistics gathering. To optimize performance, consider disabling statistics collection if you do not need them.
This property is applicable to both durable and transient processes.
The default value is -1.


LargeDocumentThreshold

The largedocumentthreshold property sets the large XML document persistence threshold. This is the maximum size (in kilobytes) of a BPEL variable before it is stored in a separate table from the rest of the instance scope data.
This property is applicable to both durable and transient processes.
Large XML documents impact the performance of the entire Oracle BPEL Server if they are constantly read in and written out whenever processing on an instance must be performed.
The default value is 10000 (100 kilobytes).


Validate XML

The validateXML property validates incoming and outgoing XML documents. If set to True, the Oracle BPEL Process Manager applies schema validation for incoming and outgoing XML documents. Nonschema-compliant payload data is intercepted and displayed as a fault.
This setting is independent of the SOA composite application and SOA Infrastructure payload validation level settings. If payload validation is enabled at both the service engine and SOA Infrastructure levels, data is checked twice: once when it enters the SOA Infrastructure, and again when it enters the service engine
CAUTION: Enabling XML payload validation can impact performance.
This property is applicable to both durable and transient processes.
The default value is False.



SyncMaxWaitTime

The SyncMaxWaitTime property sets the maximum time the process result receiver waits for a result before returning. Results from asynchronous BPEL processes are retrieved synchronously by a receiver that waits for a result from Oracle BPEL Server.
The default value is 45 seconds.


InstanceKeyBlockSize

The InstanceKeyBlockSize property controls the instance ID range size. Oracle BPEL Server creates instance keys (a range of process instance IDs) in batches using the value specified. After creating this range of in-memory IDs, the next range is updated and saved in the ci_id_range table.
For example, if instanceKeyBlockSize is set to 100, Oracle BPEL Server creates a range of instance keys in-memory (100 keys, which are later inserted into the cube_instance table as cikey). To maintain optimal performance, ensure that the block size is larger than the number of updates to the ci_id_range table.
The default value is 10000.


MaxRecoverAttempt

You can configure the number of automatic recovery attempts to submit in the same recoverable instance. The value you provide specifies the maximum number of times invoke and callback messages are recovered. Once the number of recovery attempts on a message exceeds the specified value, a message is marked as nonrecoverable.
When a BPEL instance makes a call to another server using invokeMessage, and that call fails due to a server down, validation error, or security exception, the invokeMessage is placed in a recovery queue and BPEL attempts to retry those messages. When there are many messages, and a majority of them are being sent to the same target, the target can become overloaded. Setting the appropriate value of MaxRecoveryAttempt will prevent excessive load on servers that are targeted from BPEL web service calls.










Amazon Bedrock and AWS Rekognition comparison for Image Recognition

 Both Amazon Bedrock and AWS Rekognition are services provided by AWS, but they cater to different use cases, especially when it comes to ...