| Oracle® Application Server Performance Guide 10g Release 3 (10.1.3.1.0) Part Number B28942-01 |
|
|
View PDF |
| Oracle® Application Server Performance Guide 10g Release 3 (10.1.3.1.0) Part Number B28942-01 |
|
|
View PDF |
Oracle BPEL Process Manager provides a number of property settings that can be configured to optimize performance at the process, domain, application server, Java Virtual Machine (JVM), and dehydration store database levels. This chapter describes these property settings and provides recommendations on how to use them.
This chapter contains the following sections:
This section provides an overview of key Oracle BPEL Process Manager tuning concepts. Review this section before attempting to configure any property settings.
This section contains the following topics:
Domain and process configuration properties can be set at two different levels in Oracle BPEL Process Manager:
Domain level: enables you to configure all processes deployed in a specific domain.
Process level: enables you to specify which processes to configure, and which not to configure, in a specific domain. If a setting at the domain level conflicts with the same setting at the process level, the process level setting take priority.
Oracle BPEL Process Manager uses the dehydration store database to maintain long-running asynchronous processes and their current state information in a database while they wait for asynchronous callbacks. Storing the process in a database preserves the process and prevents any loss of state or reliability if a system shuts down or a network problem occurs. There are two types of processes in Oracle BPEL Process Manager. These processes impact the dehydration store database in different ways.
Transient processes: this process type does not incur any intermediate dehydration points during process execution. If there are unhandled faults or there is system downtime during process execution, the instances of a transient process do not leave a trace in the system. Instances of transient processes cannot be saved in-flight (whether they complete normally or abnormally). Transient processes are typically short-lived, request-response style processes. The synchronous process you design in Oracle JDeveloper is an example of a transient process.
Durable processes: this process type incurs one or more dehydration points in the database during execution because of the following activities:
OnAlarm branch in a pick activity
Instances of durable processes can be saved in-flight (whether they complete normally or abnormally). These processes are typically long-living and initiated through a one-way invocation. Because of out-of-memory and system downtime issues, durable processes cannot be memory-optimized. The asynchronous process you design in Oracle JDeveloper is an example of both transient and durable processes.
There are two types of invocations into BPEL process instances:
A one-way invocation: a request-only operation and has only an inbound message.
A two-way invocation: a request-and-response operation. The caller thread is blocked until a response is ready.
Table 7-1 describes the use of one-way and two-way invocations.
Table 7-1 One-Way and Two-Way Invocations
| Use | One-Way Invocation | Two-Way Invocation |
|---|---|---|
<operation name="oneway"> <input message="in"/> </operation> |
<operation name="twoway"> <input message="in"/> <output message="out"/> </operation> |
|
|
Variable declarations in BPEL activities |
<receive operation="oneway" variable="in"/> |
<receive operation="twoway" variable="in"/> ... <reply operation="twoway" variable="out"/> |
|
Through-delivery service |
The request is saved in the delivery service. The caller thread does not block until the message is delivered to the targeted instance. |
The request is delivered into Oracle BPEL Server and the targeted BPEL instance. The caller thread is blocked until the response is ready. |
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.
Over its life cycle, a BPEL instance in its current state of execution can be saved multiple times in the dehydration store database. There are two cases in which this occurs:
When the instance is waiting for an event. It can be either an alarm or an invocation message. This happens when one of the following BPEL activities is being executed:
OnMessage branch of a pick activity
When a BPEL instance is saved to the dehydration store database, the instance is known as being dehydrated. When the event later occurs (the alarm expires or the message comes in), the instance is read from the database and resumes execution.
After a nonidempotent activity. Instance storage is necessary here if you want to retry the steps. The retry occurs from the steps after the nonidempotent activity.
For two-way invocations, if the process being called is a transient process, Oracle BPEL Server honors the caller's Java Transaction API (JTA) transaction. If the process being called is a durable process, meaning an in-flight database save can be occurring, Oracle BPEL Server creates a new transaction.
Review the BPEL threading model details in this section before attempting to configure any property settings.
Figure 7-1 shows thread usage during a request-response and one-way process instance invocation.
In Figure 7-1, the client is running in thread T1. When the caller initiates a process instance, the same thread is used during processing. Eventually, when database operations must be performed, the thread obtains a database connection (C1 in Figure 7-1) from the connection pool.
In Figure 7-1, the one-way invocation client is running in thread T2. When the client initiates a process instance, the invocation request is placed in a queue. At this point, thread T2 is released by Oracle BPEL Server and the caller can continue its own processing. Inside Oracle BPEL Server, a message-driven bean (MDB), WorkerBean, monitors the queue for invocation requests. When a message is dequeued, Oracle BPEL Server allocates a separate thread (T3) to process the message. This thread is used by Oracle BPEL Process Manager to process the instance. When database operations must be performed, the thread obtains a database connection from the connection pool.
From Figure 7-1 and the previous sections, some important relationships can be derived for properly setting the threading and connection pooling parameters.
The number of concurrent instances being processed is determined by the number of request-response client requests and the number of WorkerBean threads allocated. The following relationship can be stated.
Maximum DB Connections >= (WorkerBean listener threads) + (Maximum concurrent request-response invocations)
The dspMaxThreads property allocates WorkerBean threads to various domains. This leads to the following relationships:
If only one domain exists, these formulas can be simplified further:
dspMaxThreads = (WorkerBean listener threads) Maximum DB Connections >= (dspMaxThreads) + (Maximum concurrent request-response invocations)
This section describes process level performance tuning properties.
Process level performance properties are set in the bpel.xml file for a specific BPEL process. This file is in the same directory as the process's .bpel file. After modifying the settings in the JDev_Oracle_Home\jdev\mywork\workspace_name\process_name\bpel\bpel.xml file, the process must be redeployed for the new settings to take effect.
|
Note: You can also set these properties in the Deployment Descriptor Properties window of Oracle JDeveloper. |
This property controls the type (and amount) of data to save after instance completion.
When process instances complete, Oracle BPEL Server by default saves the final state (for example, the variable values) of the process. If you do not need to save these values after completion, you can set this property to save only instance metadata (completion state, start and end dates, and so on). This property is applicable to transient BPEL processes.
This property is used only when the inMemoryOptimization performance property is set to true. Use the completionPersistLevel property in conjunction with the completionPersistPolicy property.
This property can greatly impact database growth (in particular, the cube_instance, cube_scope, and work_item tables). It can also impact throughput (due to reduced I/O).
|
See Also:
|
This property has the following values:
all (default): Oracle BPEL Server saves the complete instance, including the final variable values, work item data, and audit data. This setting causes the database to grow in size.
instanceHeader: The Oracle BPEL Process Manager saves only the instance metadata.
In the following example, only faulted instances are persisted (completionPersistPolicy=faulted). For the faulted instances, all variable values associated with the instance are saved (competionPersistLevel=All).
<BPELSuitcase>
<BPELProcess src="HelloWorld.bpel" id="HelloWorld">
...
<configurations>
<property name="inMemoryOptimization">true</property>
<property name="completionPersistPolicy">faulted</property>
<property name="completionPersistLevel">All</property>
</configurations>
</BPELProcess>
</BPELSuitcase>
This property controls if and when to persist instances. If an instance is not saved, it does not appear in Oracle BPEL Control. This property is applicable to transient BPEL processes.
This property is only used when inMemoryOptimization is set to true. If you set completionPersistPolicy to a value other then off, you can then set completionPersistLevel to more finely tune the persistence data to save.
This parameter strongly impacts the amount of data stored in the database (in particular, the cube_instance, cube_scope, and work_item tables). It can also impact throughput.
This property has the following values:
on: (default): Completed instances are saved normally.
deferred: Completed instances are saved with a different thread and in another transaction. If a server fails, some instances may not be saved.
faulted: Only faulted instances are saved.
off: No instances (and their data) are saved.
In the following example, completionPersistPolicy is set to deferred:
<BPEL Suitcase>
<BPELProcess src="HelloWorld.bpel" id="HelloWorld">
. . .
<configurations>
<partnerLinkBinding name="PartnerService">
<property name="inMemoryOptimization">true</property>
<property name="completionPersistPolicy">deferred</property>
</partnerLinkBinding>
</configurations>
</BPELProcess>
</BPEL Suitcase>
A BPEL invoke activity is by default an idempotent activity, meaning that the BPEL process does not dehydrate instances immediately after invoke activities. Therefore, if idempotent is set to true and Oracle BPEL Server fails right after an invoke activity executes, Oracle BPEL Server performs the invoke again after restarting. This is because no record exists that the invoke activity has executed. This property is applicable to both durable and transient processes.
If idempotent is set to false, the invoke activity is dehydrated immediately after execution and recorded in the dehydration store. If Oracle BPEL Server then fails and is restarted, the invoke activity is not repeated, because Oracle BPEL Process Manager sees that the invoke already executed.
When idempotent is set to false, it provides better failover protection, but at the cost of some performance, since the BPEL process accesses the dehydration store much more frequently. This setting can be configured for each partner link in the bpel.xml file.
Setting this parameter to true can significantly improve throughput. However, as mentioned previously, you must ensure that the partner's service can be safely retried in the case of a server failure. 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.
This property has the following values:
false: activity is dehydrated immediately after execution and recorded in the dehydration store
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.
The following bpel.xml file example shows the idempotent property. This example shows a one-way invocation message being saved to the dehydration store database. This property can be set for each partner link.
<BPELSuitcase>
<BPELProcess src="Invoke.bpel" id="Invoke">
<partnerLinkBindings>
. . .
<partnerLinkBinding name="PartnerService">
<property name="wsdlLocation">
partner-wsdl
</property>
<property name="idempotent">false</property>
</partnerLinkBinding>
</partnerLinkBindings>
</BPELProcess>
</BPELSuitcase>
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, Oracle BPEL Server keeps the instances of this process in memory only during the course of execution. This property can only be set to true for transient processes (that is, those that do not contain any middle process receive, pick, or wait activities).
The default for this property is false, which means that instances are persisted completely and recorded in the dehydration store database for a synchronous BPEL process.
When inMemoryOptimization is set to true, dehydration is deactivated, and Oracle BPEL Process Manager keeps instances in memory only. The settings for the completionPersistPolicy and completionPersistLevel properties are also examined to determine persistence behavior. The inMemoryOptimization property can improve throughput when set to true and, in conjunction with these two other properties, can minimize database growth.
This property has the following values:
false (default): instances are persisted completely and recorded in the dehydration store database for a synchronous BPEL process.
true: Oracle BPEL Process Manager keeps instances in memory only.
The following bpel.xml file example shows the inMemoryOptimization property for the synchronous Hello World BPEL process:
<BPEL Suitcase>
<BPELProcess src="HelloWorld.bpel" id="HelloWorld">
. . .
<configurations>
<property name="inMemoryOptimization">true</property>
</configurations>
</BPELProcess>
</BPEL Suitcase>
This property can improve performance when executing multiple branches of a flow or flowN activity. By default, Oracle BPEL Process Manager executes in a single thread, 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 setting can be configured for each partner link in the bpel.xml file. 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 flowN 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.
This property has the following values:
true : Oracle BPEL Server spawns a new thread to execute the invocation. This thread is essentially the InvokerBean message driven bean thread. If the process has additional nonblocking invoke activities, increase the InvokerBean thread value. You may also need to increase the connection pool maximum size:
connection pool size >= (InvokerBean listener threads + WorkerBean listener threads + maximum concurrent request-response invocations
false (default): Oracle BPEL Server executes the invoke activity in the single process thread.
The following bpel.xml file example enables the nonBlockingInvoke property:
<BPELSuitcase>
<BPELProcess src="Invoke.bpel" id="Invoke">
<partnerLinkBindings>
. . .
<partnerLinkBinding name="PartnerService">
<property name="wsdlLocation">
partner-wsdl
</property>
<property name="nonBlockingInvoke">true</property>
</partnerLinkBinding>
</partnerLinkBindings>
</BPELProcess>
</BPELSuitcase>
Instance data occupies space in Oracle BPEL Process Manager schema tables. Table 7-2 describes the tables that are impacted by instance data growth. A brief description is provided of each table. The values to which you can set some domain level performance properties described in "Domain Level Performance Tuning" impact the growth of these tables.
Table 7-2 Oracle BPEL Process Manager Tables Impacted By Instance Data Growth
| Table Name | Table Description |
|---|---|
|
Stores audit details that can be logged through the API. Activities such as an assign activity log the variables as audit details by default. You can set this behavior through the auditLevel property in Oracle BPEL Control under Manage BPEL Domain > Configuration. Audit details are separated from the See Also: "auditDetailThreshold BPEL Property" and "auditLevel BPEL Property" |
|
|
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 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 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 incoming (invocation) messages (messages that result in the creation of an instance). This table only stores the metadata for a message (for example, current state, process identifier, and receive date). |
|
|
Stores metadata about columns defined in the Oracle BPEL Process Manager schema ( |
|
|
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, |
This section describes domain level performance tuning properties.
Oracle recommends that you modify these settings in Oracle BPEL Control under Manage BPEL Domain > Configuration. Oracle BPEL Control checks the existing settings and any new settings entered, and validates them without requiring a restart. Domain level performance settings are located in the SOA_Oracle_Home\bpel\domains\domain_name\config\domain.xml file. If you directly edit the domain.xml file, you must restart Oracle BPEL Server for the new settings to take effect.
The following properties display in Oracle BPEL Control under Manage BPEL Domain > Configuration. These properties have empty Name and Comment columns in the Configuration tab. Do not modify these properties; this has no impact on system performance tuning.
cbCacheHighWatermark
cbCacheLowWatermark
cbCachePolicy
cbCacheUnits
instCacheUnits
invCacheHighWatermark
invCacheLowWatermark
invCachePolicy
invCacheUnits
subCacheHighWatermark
subCacheLowWatermark
subCachePolicy
subCacheUnits
Instead, see the following subsections for details about properties that can be set to optimize performance.
This 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.
This property is applicable to durable processes.
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 50 kilobytes.
This property sets the audit trail logging level. This process is applicable to both durable and transient processes.
This property controls the amount of audit events logged by a process. This setting greatly impacts performance because more audit events means more database inserts into the audit_trail table. This audit information is used only for viewing the state of the process from Oracle BPEL Control.
Use this property if you do not want to store all audit information. Choose the level according to your business requirement. Auditing information has a significant impact on database growth and throughput. For optimal performance, set this property to the lowest acceptable level.
This property has the following values:
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. This setting is recommended for larger payload processes.
production: all events are logged. The audit details for assign activities are not logged; the details for all other activities are logged. This setting is recommended for smaller payload processes.
development (default): all events are logged; all audit details for all activities are logged.
This property sets the BPEL process compiler classpath.
This is the server-side BPEL process compiler classpath. Any user-specific classes and libraries used by a BPEL Java exec activity (that have not been packaged in the BPEL archive) must be specified in this classpath. This enables the server-side BPEL process compiler to successfully compile the BPEL process.
This process is applicable to both durable and transient processes.
The default value is:
Oracle_Home\bpel\system\classes; Oracle_Home\bpel\lib\j2ee_1.3.01.jar
This property sets the domain data source JNDI name.
This data source can refer to any data source (JTA is not required).
This process is applicable to both durable and transient processes.
The default value is jdbc/BPELServerDataSourceWorkflow.
|
WARNING: Oracle recommends that this property remain set to the default value of on. If you set this property to off and your system fails, you lose messages. Exercise extreme care if changing this property setting from the default value. |
This property enables and disables database persistence of messages entering Oracle BPEL Server. By default, incoming requests are saved in the following delivery service database tables:
These requests are later acquired by Oracle BPEL Server worker threads and delivered to the targeted BPEL process. In the case where performance is preferred over reliability, persisting the incoming messages in the database can be skipped. This property persists delivery messages and is applicable to durable processes.
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, some messages can get lost. In Oracle BPEL Control (under Manage BPEL Domain >Threads), you can monitor the size of the delivery cache by viewing the New Instance Requests and Callback Requests statistics in the Pending Requests section. The Scheduled column indicates the number of cached messages.
This property has the following values:
on (default): delivery messages are persisted in the database
off: incoming delivery messages are kept only in the in-memory cache. If more messages are delivered, the system can become overloaded (messages become backlogged in the scheduled queue) and you receive out-of-memory errors. Tune the number of WorkerBean threads to accommodate the number of incoming messages.
off.immediate: directs Oracle BPEL Server to bypass the scheduling of messages in the invoke queue, and invokes the BPEL instance synchronously.
This property sets the number of seconds between triggers of the dispatcher agent. This agent cleans up any messages in the dispatcher layer that have not been processed due to a failure in the JMS layer.
This process is applicable to durable processes.
The default value is 120 seconds.
This property sets the percentage of active threads to be tasked to process incoming invocation messages. After a thread has finished processing a message, it can be tasked again to process an Oracle BPEL Server or invocation message, depending upon the current thread allocation situation.
This process is applicable to durable processes.
The default value is 0.4 (40%).
This 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 transactionality 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 timeout limit.
This process is applicable to durable processes.
The default value is 600 activities.
This property sets the maximum number of active dispatcher threads that process messages during peak load times. This property is applicable to durable processes and is dependent on the application server configuration.
This is the simplest way to improve the performance and scalability of the domain. Oracle BPEL Server uses MDB threads to process Oracle BPEL Server messages. The maximum value for this property is dependent upon the Oracle BPEL Server's MDB J2EE listener threads setting. For Oracle Application Server, this count is configured in the orion-ejb-jar.xml deployment descriptor file.
For example, if the total number of MDB J2EE listener threads is 120, the value of dspMaxThreads can be set to 120 or less. If you have configured multiple domains, the sum of the dspMaxThreads settings for all domains must not exceed the MDB J2EE listener threads setting.If the CPU utilization of your application server and database hosts are well below capacity, try increasing this value and the MDB J2EE listener threads setting when necessary. If the CPUs are still not fully utilized, then consider running multiple Oracle BPEL Server instances.
|
See Also:
|
The default value is 100 threads.
This property sets the minimum number of active dispatcher threads that process messages during peak load times.
If the current number of active threads is under this number, the load factor is not taken into consideration when determining whether or not to allocate a new thread.
This process is applicable to durable processes.
The default value is 5 threads.
This property sets the maximum number of times a failed expiration call (in a wait activity or an onAlarm branch of a pick activity) is retried before failing.
If the activity or instance targeted by the expiration call cannot be found, the call is rescheduled again.
The retry count does not include the first (original) attempt by the expiration call.
This process is applicable to durable processes.
The default value is 5.
This property sets the maximum time (in seconds) in which an idempotent service must successfully complete an activity. If an idempotent service takes longer than this time to complete, the service is considered nonidempotent and the current transaction is committed to the database. This feature prevents lengthy services from having to redo work in case another service in the idempotent chain fails.
The default value is 30 seconds.
This property controls the instance ID range size. Oracle BPEL Server creates instance keys (a range of process instance IDs) in batches using this number. 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). If the block size is smaller then the number of updates to the ci_id_range table, this may cause performance issues.
The default value is 10000.
This property sets the maximum number of in-flight instances that can be placed in the cache before pruning occurs. Once the high watermark is reached, the cache removes (prunes) enough older instances from cache to reach the low watermark value (set with the instCacheLowWatermark property). Pruned instances can be retrieved as needed from the dehydration store. This property is applicable to durable processes.
This value is only used when the instCachePolicy property is set to lru or hybrid. Consider the following factors when setting this property:
The number of in-flight instances Oracle BPEL Process Manager is expected to handle at any point in time
The amount of memory each process instance takes. The memory usage can be determined using a Java Profiler.
You can run a single instance through the system and measure the corresponding increase in memory utilization.
If this property is set too high, your system can encounter OutOfMemoryException error messages. The system can also actually slow down if this value is set too high because the garbage collector runs more frequently. To monitor the garbage collector, use Sun's visual garbage collection (GC) tool (http://java.sun.com/performance/jvmstat).
The default value is 3000; zero implies no limit.
This property sets the number of in-flight instances to which the cache is pruned when pruning occurs. This property is applicable to durable processes.
When the high watermark in the cache is reached, the cache removes enough instances to reach this level.
Cache pruning occurs when the cache size grows to the high watermark value (set with the instCacheHighWatermark property). This instCacheLowWatermark property controls how much pruning occurs. The default value is 75% of the high watermark setting. This indicates the cache is reduced to 75% of the high watermark value when pruning occurs. This value is only used when the instCachePolicy property is set to lru or hybrid.
Monitor instance cache statistics by going to Manage BPEL Domain > Threads in Oracle BPEL Control. In the Server cache statistics section at the bottom of this page is the instance cache entry. You can view the cache size and hit percentage. If the hit percentage is quite low, consider increasing your cache size or the low watermark value.
If this property is set too high, your system can encounter OutOfMemoryException errors. The system can also actually slow down if this value is set too high. This is because the garbage collector must run more frequently. To monitor the garbage collector, use Sun's visual GC tool (http://java.sun.com/performance/jvmstat).
The default value is 2250 (75%).
This property sets the eviction policy to use when removing in-flight instances from the cache. This property is applicable to durable processes.
This property takes effect only when the optCacheOn property is set to true.If you want to fine tune cache management, use this property. If the number of process instances that must be kept in memory is well known, Oracle recommends the lru setting. When using the lru setting, the instCacheHighWatermark and instCacheLowWatermark properties must also be set.
|
Note: Some JVM implementations have been observed to display anOutOfMemoryException error message when cache values are set to auto. This happens because the auto caching setting relies on JVM soft references. If you encounter this error, set the caching value to lru. |
This property has the following values:
lru: least recently used; this setting first removes those instances that have not been accessed for the longest period of time. This setting is recommended.
auto (default): delegates the removal decision to the JVM. Instances are removed when the garbage collector reaps soft references.
soft-lru: combination of lru and auto.
This property sets the invoker queue connection pool minimum size. This value must match the number of invoker threads. If the invoker threads are set to 200, this value can be set to 200 to avoid JMS warm up.
This property is applicable to both durable and transient processes.
The default value is 25.
This 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 location 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 50 kilobytes.
This property sets the minimum BPEL activity wait.
If the wait time for a wait activity or an onAlarm branch of a pick activity is less than the value defined here, the wait is ignored.
This property is applicable to durable processes.
The default value is 2 seconds.
This property sets the in-memory cache for in-flight instances. This property is applicable to durable processes.
If set to true, Oracle BPEL Process Manager attempts to load active instances from in-memory cache rather than looking them up from the database. To disable optimization, specify a value other than true.
Set this property to false if your process is long running and the subprocesses do not immediately call back. Consider this if you are dealing with shorter processes, which expect many callbacks.
Setting this property to true necessitates setting the following caching-related settings:
instCacheHighWatermark
instCacheLowWatermark
instCachePolicy
If you can meet your performance goals without using the cache, Oracle recommends leaving this setting as false to simplify administration and tuning.
|
Note: Enabling the cache may adversely impact performance. This can happen if cache values are set too high, causing the JVM garbage collector to run at frequent intervals. Use Sun's visual GC tool (http://java.sun.com/performance/jvmstat) to monitor the garbage collector. |
This property has the following values:
true: Oracle BPEL Server attempts to load active instances from in-memory cache rather than looking them up from the database.
false (default): Oracle BPEL Server loads the instance from the database every time.
|
Note: Oracle recommends that you do not change this parameter. |
This property sets a routing shortcut for idempotent services.
If set to true, Oracle BPEL Server attempts to process as many activities as possible within the same transaction if the activity services are idempotent.
This property is applicable to durable processes.
The default value is true. To disable optimization, specify a value other than true.
The default value is true.
|
Note: Oracle recommends that you do not change this parameter. |
This property sets a short-cut for a local SOAP request.
Local SOAP calls are normally performed with an internal call instead of sending a message through the SOAP stack.
The default behavior for the Oracle BPEL Process Manager is to optimize all by bypassing the SOAP stack. To disable optimization, specify a value other than true.
This property is applicable to both durable and transient processes.
true (default): Local SOAP calls bypass the SOAP stack.
false: Local SOAP calls go through the SOAP stack.
This property sets the number of seconds to wait since the last time Oracle BPEL Server checked the BPEL archive before checking it again. Checking means to check the last modified time stamp on the BPEL archive for a particular process. If the specified number of seconds has passed and the BPEL archive file has been modified since the last time checked, the process is refreshed from the new archive. If not enough time has passed since the last time the stale check was performed, the currently-loaded process classes are used.
This property is applicable to both durable and transient processes.
To disable process checking, use a value of -1. In this case, once a process has been loaded, Oracle BPEL Server never checks if a newer version of the same process has been deployed.
The default value is 1 second.
|
Note: While this property does display in Oracle BPEL Control, Oracle recommends that you do not use this property. This property has been deprecated. |
This property relaxes enforcement of the Business Process Execution Language for Web Services Specification Version 1.1 assign rules. If set to true, Oracle BPEL Process Manager does not apply rules while assigning BPEL variables. For example, Oracle BPEL Process Manager does not display an error about null assignments (which are not allowed in the BPEL specifications).
This property is applicable to both durable and transient processes.
This property has the following values:
false (default): does not relax assignment rules.
true: relaxes assignment rules.
This property sets the maximum time (in seconds) for a service to successfully complete an activity. If a service takes longer than this time to complete, the service is considered slow. Oracle BPEL Process Manager collects statistics on slow services.
This property is applicable to durable processes.
The default value is 1 second.
This property sets the size of the most-recently processed request list. After each request is finished, statistics for the request are kept in a list. A value less than or equal to zero disables statistics gathering.
This property is applicable to both durable and transient processes.
You can view statistics from Oracle BPEL Control under Manager BPEL Domain > Statistics.
The default value is 1000.
This 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.
This property is applicable to transient processes.
The default value is 45 seconds.
This property sets the domain transactional data source JNDI name. This data source must be configured for JTA support.
This property is applicable to both durable and transient processes.
The default value is jdbc/BPELServerDataSource.
This property specifies the inquiry URL of the Universal Description, Discovery, and Integration (UDDI) version 3-compliant registry.
If you use virtual locations, meaning that you only reference the abstract WSDL in your partner link and provide a property named registryServiceKey in the deployment descriptor on the partner link binding level, this property is used to connect to the UDDI registry to retrieve the information.
There is no default value.
This 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.
This property is applicable to both durable and transient processes.
The default value is false.
This property sets the worker queue connection pool minimum size. This value must match the number of worker threads. If the number of worker threads is 200, this value can be set to 200 to avoid JMS warm up.
This property is applicable to durable processes.
The default value is 25.
The parameters described in this section are set at the Oracle Application Server level. You must restart the OC4J instance for these parameters to take effect.
This section contains the following topics:
|
See Also: Oracle Application Server Administrator's Guide for instructions on starting and stopping Oracle Application Server |
Oracle BPEL Server uses JTA to achieve atomicity. The transaction timeout value is set by default to 60000 milliseconds in the transaction-manager.xml file. The location of this file depends on the method by which you installed Oracle BPEL Process Manager:
For Oracle Application Server SOA installations, the file is located in SOA_Oracle_Home\j2ee\home\config.
For Oracle BPEL Process Manager installations, the file is located in SOA_Oracle_Home\bpel\system\appserver\oc4j\j2ee\home\config.
You can sometimes experience transaction rollback errors due to timeouts, especially when Oracle BPEL Server is under stress. The timeout can happen for many reasons:
Insufficient resources (for example, not enough database connections in the connection pool, the server thread waits for 60 seconds and displays a timeout error, and so on).
Large document manipulation (for example, database writes of very large documents can take longer than 60 seconds).
Change this value according to your process. The following example sets the timeout to 120 seconds:
<transaction-config timeout="120000" />
If your process invokes partners that take longer than the specified timeout threshold, call them using a one-way request or set the nonBlockingInvoke partner link property to true in the bpel.xml deployment descriptor file.
To increase performance, Oracle recommends removing the max-instances attribute for all of Oracle BPEL Server's EJBs in the orion-ejb-jar.xml file. For the Oracle BPEL Process Manager for OracleAS Middle Tier installation type, this file is located in SOA_Oracle_Home\j2ee\home\application-deployments\orabpel\ejb_ob_engine.
This enables the application server to allocate more resources to heavily-used beans.
Oracle BPEL Server uses an MDB called WorkerBean to perform processing. Therefore, it is important to allocate enough threads to this MDB. Otherwise, resource utilization is not optimal. The following code from the orion-ejb-jar.xml file shows an allocation of 70 threads.
<message-driven-deployment name="WorkerBean" destination-location="jms/collaxa/BPELWorkerQueue" connection-factory-location="jms/collaxa/BPELWorkerQueueFactory" listener-threads="70" min-instances="100"> <ejb-ref-mapping name="ejb/local/DispatcherLocalBean" /> .. .. </message-driven-deployment>
The invoker bean is used only for nonblocking invoke activities. If you set some invokes to be nonblocking, increase the number of threads allocated to the InvokerBean. The following orion-ejb-jar.xml code shows an allocation of 30 threads.
<message-driven-deployment name="InvokerBean" destination-location="jms/collaxa/BPELInvokerQueue" connection-factory-location="jms/collaxa/BPELInvokerQueueFactory" listener-threads="30" min-instances="100"> <ejb-ref-mapping name="ejb/local/ProcessManagerLocalBean" /> … … </message-driven-deployment>
Oracle BPEL Server obtains database connections using an application server JTA data source. Oracle BPEL Server by default is configured to use the Oracle Database Lite dehydration store. For stress testing and production, Oracle recommends that you use Oracle Database 10g. Oracle Database Lite packaged with the default installation to ease the initial developer experience.
Be aware of the following issues when configuring the Oracle BPEL Server data source entry. For the Oracle BPEL Process Manager for OracleAS Middle Tier installation type, the data source entry is located in the SOA_Oracle_Home\j2ee\home\config\data-sources.xml file.
When configuring the data source, ensure that the connection pool has enough free connections to serve Oracle BPEL Server.
The connection pool size must be greater than or equal to the sum of the dspMaxThreads property value in Oracle BPEL Control. If you have configured multiple domains, add all dspMaxThreads property values and compare that value with the data source's max-connections value. The default max-connections value is unlimited.
For Oracle Database 10g, the data source must also use the thin driver. For the Oracle9i Database, Oracle Call Interface (OCI) performs slightly better.
When database persistence is enabled, Oracle BPEL Server generally performs better with JDBC statement caching enabled. Statement caching eliminates overhead due to repeated cursor creation and repeated statement parsing and creation. Statement caching also reduces the overhead of communication between the application server and the database server. The following data source has been configured to use an Oracle Database and enable a JDBC statement cache size of 200.
<connection-pool name="BPELPM_CONNECTION_POOL">
<connection-factory factory-class="oracle.jdbc.OracleDriver"
user="orabpel"
password="->pwForOrabpel"
url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=tcp)(HOST=hostname)(PORT=port)))(CONNECT_DATA=(SERVICE_
NAME=SID)))"
num-cached-statements="200" />
</connection-pool>
<managed-data-source name="BPELServerDataSource"
connection-pool-name="BPELPM_CONNECTION_POOL"
jndi-name="jdbc/BPELServerDataSource" tx-level="global" />
<managed-data-source name="BPELServerDataSourceWorkflow"
connection-pool-name="BPELPM_CONNECTION_POOL"
jndi-name="jdbc/BPELServerDataSourceWorkflow" tx-level="local" />
<managed-data-source name="BPELSamplesDataSource"
connection-pool-name="BPELPM_CONNECTION_POOL"
jndi-name="jdbc/BPELSamplesDataSource" />
|
See Also:
|
JVM parameters can have an impact Oracle BPEL Server performance. The major factors that impact performance relate to the heap size. The heap size controls the amount of memory the JVM uses. If your BPEL process instance runs on a dedicated host, set the heap size value as high as possible.
Another important heap configuration is the garbage collector's generational settings. The garbage collector optimizes collection by classifying objects by how long they live. Most Oracle BPEL Server objects are short-lived; thus they live in the Eden space. Oracle recommends sizing the Eden space to be 60 to 70 percent of the total heap size.
The JVM -Xmn setting startup option sets an explicit value for the Eden space size. Do the following to set this option:
Calculate the 60-70 percent value, based on the specified maximum heap size.
Use the calculated value to set the JVM -Xmn command line parameter.
Take the following steps to change JVM command line options:
Navigate to the Home page for the OC4J instance.
Click Administration.
If necessary, expand the Properties section of the table by clicking the Expand icon. Then, click the Go to Task icon in the Server Properties row.
In the Command Line Options area, modify or change the appropriate command line options in the Options table.
Click Apply.
Navigate to the Cluster Topology page, select the OC4J instance that you modified, and click Restart. On the Confirmation page, click Yes.
Oracle BPEL Server performance is related to the dehydration store's capacity. Oracle recommends the following:
Increasing the size of each redo log file to a large value (for example, 1 GB)
Creating a separate database tablespace for Oracle BPEL Server
The database parameters shown in Table 7-3 impact Oracle BPEL Process Manager performance. The specific values to use depend on your hardware configuration.
Table 7-3 Database Parameters Impacting Oracle BPEL Process Manager Performance
| Parameter Name | Sample Value |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See Also: Oracle Database Tuning and Oracle Database Reference for your Oracle Database release:
|
This chapter describes how to configure Oracle BPEL Process Manager property settings to optimize performance at the process, domain, application server, Java Virtual Machine (JVM), and dehydration store database levels. This chapter describes these property settings and provides recommendations on how to use them.
