Oracle Business Process Execution Language (BPEL) Process Manager provides several property settings that can be configured to optimize performance at the composite, fabric, application and server levels. This chapter describes these property settings and provides recommendations on how to use them.
This chapter contains the following sections:
BPEL is the standard for assembling a set of discrete services into an end-to-end process flow, radically reducing the cost and complexity of process integration initiatives. Oracle BPEL Process Manager offers a comprehensive and easy-to-use infrastructure for creating, deploying and managing BPEL business processes.
For more information, see "Configuring BPEL Process Service Components and Engines" in Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite and "Using the BPEL Process Service Component" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
This section describes the performance tuning properties at the BPEL engine level. They can be configured using Oracle Enterprise Manager. For more information , see "Configuring BPEL Process Service Engine Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
Note:
The configuration examples and recommended settings described in this chapter are for illustrative purposes only. Consult your own use case scenarios to determine which configuration options can provide performance improvements.
When the dispatcher must schedule a dispatch message for execution, it can enqueue the message into a thread pool. Each dispatch set can contain a thread pool (java.util.concurrent.ThreadPoolExecutor). The BPEL thread pool implementation notifies the threads when a message has been enqueued and ensures the appropriate number of threads are instantiated in the pool.
Note:
dspMinThreads
, dspMaxThreads
and dspInvokeAllocRatio
configuration properties are deprecated in Oracle 11g. In addition, the invoke threads have their own pool in Oracle 11g so the dspInvokeAllocRatio
is no longer required.
The dspSystemThreads
property specifies the total number of threads allocated to process system dispatcher messages. System dispatcher messages are general clean-up tasks that are typically processed quickly by the server (for example, releasing stateful message beans back to the pool). Typically, only a small number of threads are required to handle the number of system dispatch messages generated during run time.
The minimum number of threads for this thread pool is 1 and it cannot be set to 0 a or negative number.
The default value is 2
. Any value less than 1 thread is changed to the default.
The dspInvokeThreads
property specifies the total number of threads allocated to process invocation dispatcher messages. Invocation dispatcher messages are generated for each payload received and are meant to instantiate a new instance. If the majority of requests processed by the engine are instance invocations (as opposed to instance callbacks), greater performance may be achieved by increasing the number of invocation threads. Higher thread counts may cause greater CPU utilization due to higher context switching costs.
The minimum number of threads for this thread pool is 1 and it cannot be set to 0 a or negative number.
The default value is 20 threads. Any value less than 1 thread is changed to the default.
The dspEngineThreads
property specifies the total number of threads allocated to process engine dispatcher messages. Engine dispatcher messages are generated whenever an activity must be processed asynchronously. If the majority of processes deployed are durable with a large number of dehydration points (mid-process receive, onMessage, onAlarm, and wait activities), greater performance may be achieved by increasing the number of engine threads. Note that higher thread counts can cause greater CPU utilization due to higher context switching costs.
The minimum number of threads for this thread pool is 1 and it cannot be set to 0 a or negative number.
The default value is 30 threads. Any value less than 1 thread is changed to the default.
The dspMaxRequestDepth
property sets the maximum number of in-memory activities to process within the same request. After processing an activity request, Oracle BPEL Process Manager attempts to process as many subsequent activities as possible without jeopardizing the validity of the request. Once the activity processing chain has reached this depth, the instance is dehydrated and the next activity is performed in a separate transaction.
If the request depth is too large, the total request time can exceed the application server transaction time out limit.This process is applicable to durable processes.
The default value is 600 activities.
Note:
Note that the minimum number of threads for each thread pool is 1. dsp*Threads can not be set to 0 or negative.
The following properties can be set to audit levels.
The auditLevel
property sets the audit trail logging level. This configuration property is applicable to both durable and transient processes. This property controls the amount of audit events that are logged by a process. Audit events result in more database inserts into the audit_trail
table which may impact performance. Audit information is used only for viewing the state of the process from Oracle Enterprise Manager Console.
Use the Off value if you do not want to store any audit information. Always choose the audit level according to your business requirements and use cases. For more information on setting the audit level, see "Introduction to the Order of Precedence for Audit Level Settings" in Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
Value | Description |
---|---|
Inherit |
Inherits the audit level from infrastructure level. |
Off |
No audit events (activity execution information) are persisted and no logging is performed; this can result in a slight performance boost for processing instances. |
Minimal |
All events are logged; however, no audit details (variable content) are logged. |
Error |
Logs only serious problems that require immediate attention from the administrator and are not caused by a bug in the product. Using this level can help performance. |
Production |
All events are logged. The audit details for assign activities are not logged; the details for all other activities are logged. |
Development |
All events are logged; all audit details for all activities are logged. |
The auditdetailthreshold
property sets the maximum size (in kilobytes) of an audit trail details string before it is stored separately from the audit trail. If an audit trail details string is larger than the threshold setting, it is not immediately loaded when the audit trail is initially retrieved; a link is displayed with the size of the details string. Strings larger than the threshold setting are stored in the audit_details
table, instead of the audit_trail
table.
The details string typically contains the contents of a BPEL variable. In cases where the variable is very large, performance can be severely impacted by logging it to the audit trail.
The default value is 50000 (50 kilobytes).
This property specifies the strategy to persist the BPEL audit data.
Value | Description |
---|---|
syncSingleWrite (default) |
AuditTrail and dehydration are persisted to DB in one transaction. |
syncMultipleWrite |
AuditTrail and dehydration are persisted in the same thread but separate transactions. |
async |
AuditTrail and dehydration are persisted by separate threads and separate transactions. |
By default, audit messages are stored as part of the main BPEL transaction. A BPEL instance holds on to the audit messages until the flow reaches dehydration. In some use cases, for example when you have a large loop, and there is no dehydration point in the loop, a large number of audit logs are accumulated. This could lead to an out-of-memory issue and BPEL main transaction can experience timeout errors. You may consider using syncMultipleWrite
or async
to store the audit message separately from the main transaction.
When you use syncMultipleWrite
and async
auditStorePolicy
, there are a few other properties that need to be considered. Please see the sections below.
This property controls how often the engine should flush the audit events, basically after adding an event to the current batch, the engine checks to see if the current batch byte size is greater than this value or not.
Consider tuning this property when async
or syncMultipleWrite
audit strageties are used. This size needs to be tuned based on the application.
This property controls how often the engine should flush the audit events, basically when it reaches this limit of the number of events, the engine would trigger the store call.
Consider tuning this property when async
or syncMultipleWrite
audit strageties are used. This size needs to be tuned based on the application.
The oneWayDeliveryPolicy
is from the Oracle 10g configuration property deliveryPersistencePolicy
.
The new configuration property name is bpel.config.oneWayDeliveryPolicy
.
WARNING:
If you set this property to async.cache
and your system fails, you may lose messages. For more information, refer to the Oracle BPEL Process Manager Administrator's Guide.
The oneWayDeliveryPolicy
property controls database persistence of messages entering Oracle BPEL Server. By default, incoming requests are saved in the delivery service database table dlv_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.
Value | Description |
---|---|
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.cache |
Incoming delivery messages are kept only in the in-memory cache. If performance is preferred over reliability, this setting should be considered. |
sync |
Directs 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. |
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.
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.
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).
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.
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.
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.
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.
This section lists the config properties of some sections of the deployment descriptor. For each configuration property parameter, a description is given, as well as the expected behavior of the engine when it is changed.
All the properties set in this section affect the behavior of the component containing the BPEL process only. Each BPEL process can be created as a component of a composite. These properties can be modified in composite.xml or in the System MBean Browser of Oracle Enterprise Manager Fusion Middleware Control. For more information, see the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
The following component properties can be tuned for performance:
This property indicates to Oracle BPEL Server that this process is a transient process and dehydration of the instance is not required. When set to True, the completionPersistPolicy is used to determine persistence behavior. This property can only be set to True for transient processes or processes that do not contain any dehydration points such as receive, wait, onMessage and onAlarm activities. The inMemoryOptimization property is set at the BPEL component level. When set to False, dehydration is disabled which can improve performance in some use cases.
Values:
This property has the following values:
False (default): instances are persisted completely and recorded in the dehydration store database.
True: The completionPersist policy is used to determine persistence behavior. See Section 13.3.1.2.
This property configures how the instance data is saved. It can only be set at the BPEL component level. The completionPersistPolicy property can only be used when inMemoryOptimization is set to be True (transient processes). Note that this parameter may affect database growth and throughput (due to reduced I/O).
Value | Description |
---|---|
On (default) |
The completed instance is saved normally |
Deferred |
The completed instance is saved, but with a different thread and in another transaction. |
Faulted |
Only the faulted instances are saved. Note: When an unhandled fault occurs, regardless of these flags, audit information of the instance is persisted within |
Off |
No instances of this process are saved. |
You can set the audit level for a BPEL process service component. This setting takes precedence over audit level settings at the SOA Infrastructure, service engine, and SOA composite application levels.
Set the bpel.config.auditLevel
property to an appropriate value in the composite.xml file of your SOA project as shown in the example below:
<component name="BPELProcess">
<implementation.bpel src="BPELProcess.bpel" />
<property name="bpel.config.auditLevel">Off</property>
</component>
Value | Description |
---|---|
Inherit |
Inherits the audit level from infrastructure level. |
Off |
No audit events (activity execution information) are persisted and no logging is performed; this can result in a slight performance boost for processing instances. |
Minimal |
All events are logged; however, no audit details (variable content) are logged. |
Error |
Logs only serious problems that require immediate attention from the administrator and are not caused by a bug in the product. Using this level can help performance. |
Production |
All events are logged. The audit details for assign activities are not logged; the details for all other activities are logged. |
Development |
All events are logged; all audit details for all activities are logged. |
You can dynamically configure a partner link at runtime in BPEL. This is useful for scenarios in which the target service that BPEL wants to invoke is not known until runtime. The following Partner Link properties can be tuned for performance:
An idempotent activity is an activity that can be retried (for example, an assign activity or an invoke activity). Oracle BPEL Server saves the instance after a nonidempotent activity. This property is applicable to both durable and transient processes.
Values:
This property has the following values:
False: Activity is dehydrated immediately after execution and recorded in the dehydration store. When idempotent
is set to False, it provides better failover protection, but may impact performance if the BPEL process accesses the dehydration store frequently.
True (default): If Oracle BPEL Server fails, it performs the activity again after restarting. This is because the server does not dehydrate immediately after the invoke and no record exists that the activity executed. Some examples of where this property can be set to True are: read-only services (for example, CreditRatingService) or local EJB/WSIF invocations that share the instance's transaction.
By default, Oracle BPEL Process Manager executes in a single thread by executing the branches sequentially instead of in parallel. When this property is set to True, the process manager creates a new thread to perform each branch's invoke activity in parallel. This property is applicable to both durable and transient processes.
Consider setting this property to True if you have invoke activities in multiple flow or flow n branches. This is especially effective if the parallel invoke activities are two-way, but some benefits can be realized for parallel one-way invokes as well.
Note:
Invocations to the same partner link will happen in sequence and not in parallel. If you invoke different partner links each time with nonBlockingInvoke
set to True, then each link will work in parallel even if all of the partner links point to the same source.
Values:
True: Oracle BPEL Server spawns a new thread to execute the invocation.
False (default): Oracle BPEL Server executes the invoke activity in the single process thread.
Enables message boundary validation. Note that additional validation can impact performance by consuming extra CPU and memory resources.
Values:
True: When set to True the engine validates the XML message against the XML schema during <receive> and <invoke> for this partner link. If the XML message is invalid then bpelx:invalidVariables
run time BPEL Fault is thrown. This overrides the domain level validateXML
property.
False (default): Disables XML validation.
Instance data occupies space in Oracle BPEL Process Manager schema tables. Data growth from auditing and dehydration can have a significant impact on database performance and throughput. See Section 13.2.2, "Audit" for audit configuration and Section 13.3.1.1, "inMemoryOptimization" for dehydration configuration. The table below describes the tables that are impacted by instance data growth. A brief description is provided of each table.
Table 13-1 Oracle BPEL Process Manager Tables Impacted by Instance Data Growth
Table Name | Table Description |
---|---|
|
Stores the audit trail for instances. The audit trail viewed in Oracle BPEL Control is created from an XML document. As an instance is processed, each activity writes events to the audit trail as XML. |
|
Stores audit details that can be logged through the API. Activities such as an assign activity log the variables as audit details by default. Audit details are separated from the |
|
Stores process instance metadata (for example, the instance creation date, current state, title, and process identifier) |
|
Stores the scope data for an instance (for example, all variables declared in the BPEL flow and some internal objects that help route logic throughout the flow). |
|
Stores incoming (invocation) and callback messages upon receipt. This table only stores the metadata for a message (for example, current state, process identifier, and receive date). |
|
Stores delivery subscriptions for an instance. Whenever an instance expects a message from a partner (for example, the receive or onMessage activity) a subscription is written out for that specific receive activity. |
|
Stores cube instance references to data stored in the |
|
Stores references to |
|
Stores tasks created for an instance. The TaskManager process keeps its current state in this table. |
|
Stores activities created by an instance. All activities in a BPEL flow have a |
|
Stores all large objects in the system (for example, |
|
Stores headers and properties information. |