There are many process level and domain level properties that we need to understand in order to fine tune the performance of our process.
For any BPEL process we have a file called bpel.xml we can set these properties over here and redeploy the project in order to make the changes take effect.
The different performance properties used are
1>Idempotent
=================
It can be set within the bpel.xml file.
General sysntax is
<partnerLinkBindings>
<property name="idempotent">true</property>
</partnerLinkBinding>
An idempotent activity is an activity that can be retried eg- the assign activity. A non-idempotent activity is an activity that can happen only once.The default value of idempotent property is true.By default, in a bpel process invoke activity is an idempotent activity, It means that the BPEL engine will not dehydrate the instance right after invoke activities. This property can be set for each partner link.If it is set to true and when you invoked a bpel process and your environment get crashed all of a sudden then when you will restart the system the invoke will be executed again.But when we will set this property to false the bpel engine will dehydrate the activity after the invoke and when you will start the server it will start from the last saved activity and not from the invoke activity.Thus it will enhance performance.
2>nonBlockingInvoke
=====================
This property is used when you have more than one invoke activity in parallel.The bpel engine by default creats a single thread and even though your invoke activities are in parallel the engine calls them sequentially essentially from left to right.We can change this behaviour by including a property called nonBlockingInvoke in order to create separate threads for each invoke activity causing the performace to increase.The default value for nonBlockingInvoke is false which mean the engine will call the invoke activity in a single process Thread.We will change it to true in order to create new threads for execution thus processing in parallel will increase the performance.
General syntax
<partnerLinkBindings>
<property name="nonBlockingInvoke">true</property>
</partnerLinkBindings>
3>inMemoryOptimization
=========================
This properties is applied only in transient process.Transient process are those process which doesnot contain any mid point activities like receive,pick or wait activities or even any idempotent activities or in other words we can say it never stops and wait for any activities in between or wait for any results in between.This property tells the engine that the process is transient process and dehydration of the instance is not required.The default value of this property is false.When it is set to true the engine will keep the instances of this process only in memory during the course of execution.
This property works in conjunction with completionPersistPolicy and completionPersistLevel.
These properties values are determined to determine the behaviour of persistence
General syntax is
<BPELProcess src="getValue.bpel" id="getValue">
.................................
<configurations>
<property name="inMemoryOptimization">true</property>
</configurations>
</BPELProcess>
4>completionPersistPolicy
============================
The completionPersistPolicy property can only be used when inMemoryOptimization is set to be true in a transient process.This property controls when to persist instances.
The default value for this property is on ,which means that the instance will be saved normally.The other values that can be used for this property are
a>off-no instance for the process will be saved.
b>faulted-Only faulted instances will be saved for the process.
c>deferred-It is more or like on status but here some of the instances may not get stored in case of a crash of server.
General syntax is
<BPELProcess src="getValue.bpel" id="getValue">
.................................
<configurations>
<property name="inMemoryOptimization">true</property>
<property name="completionPersistPolicy">off</property>
</configurations>
</BPELProcess>
You can change it accordingly as per your requirement.
5>completionPersistLevel
===========================
The completionPersistLevel property can only be used when inMemoryOptimization is set to be true in a transient processes.The default value for this property is all which mean it will store all the state of the instances.It can also have an value of
instanceHeader which means only the meta data will be stored for the instance.by saying meta data i meana completion state, start/end dates, etc.
General syntax is
<BPELProcess src="getValue.bpel" id="getValue">
...
<configurations>
<property name="inMemoryOptimization">true</property>
<property name="completionPersistPolicy">faulted</property>
<property name="completionPersistLevel">All</property>
</configurations>
</BPELProcess>
here in my case i have set it to all that is i want to store all the states of the instance for the faulted instance.
6>deliveryPersistPolicy
============================
The deliveryPersistPolicy configuration property is used to turn on and off the DB persist of asynchronous process.The default value is on which means it store asynchronous process in delivery service DB.
To change it log in to the BPel console
http://host:port/BPELConsole
switch to configuration tab.There you will find this property
Changes whether the delivery messages are persisted. Delivery messages include invoke message, callback message and subscription message.
* on - delivery messages are persisted
* off - delivery messages are kept only in memory.
The default value is "on".
Asynchronous requests by default are saved in the delivery queue database table. These requests are later picked up by the worker threads and delivered to the targeted BPEL instances. The messages can be kept in delivery queue in memory cache in case of enhanced performance.
JVM tuning is also required for which you can refer to my previous post on "JVM Tuning"
If you are on version lower than 10.1.3.4 then you also need to take care of dspMaxThreads and ReceiverThreads
As per best practices it is recommended to have sum of dspMaxThreads across all the domain less than or equal to the receiverThreads.
No comments:
Post a Comment