WebLogic Server
JDK Version
Use the latest SUN Java Virtual Machine. This can be downloaded from the SUN web site, currently JDK5 build 21 is available:
http://java.sun.com/javase/downloads/index_jdk5.jsp
Unpack this JVM into $WLS_HOME/wls and point the admin and managed servers to this new JDK;
$WLS_HOME/user_projects/domains/SOADomain/bin/setDomainEnv.sh
Oracle certification on JVM can be found here:
http://www.oracle.com/technology/software/products/ias/files/oracle_soa_certification_r3_10.1.3_matrix.xls
Memory settings
Configure the heap and memory size correctly. Do not increase the Java Heap size to large. This could lead into swapping or too much overhead in JVM. In general I suggest to set the -Xms and -Xmx equal and make these 1. Leave at least 30% memory for de rest; O/S, Apache...
Garbage collection is happening when the BPEL PM is overloaded with tasks. Full garbage collection will take place. A parameter that influences this behavior a bit, is to reduce the Java stack size. By default the stack size is 512KB. This is for each thread. If you have short running processes, they do not occupy a large stack. You can reduce the stack size. Use the value -Xss128k or even -Xss96k.
The permanent generation holds data needed by JVM to describe objects that do not have an
equivalence at the Java language level. Eg: objects describing classes and methods. Consider setting –XX:MaxPermSize equal to –XX:PermSize to minimize major collections.
If the servers contains multiple CPUs (cores) whe can use aggressive heap JVM flag. This option inspects the machine resources and attempts to set various parameters to be optimal for long-running, memory allocation-intensive jobs.
Summary; set the memory settings to:
-Xms1024m -Xmx1024m -XX: -Xss128k -XX:MaxPermSize=512m -XX:PermSize=512m -XX:+AggresiveHeap
Note; performance tests should be carried to find the optimal values. This is a best practice recommendation.
JTA timeouts
Be default the global transaction time-out period of WLS is set to 90 seconds. In a BPEL PM environment this is to low. Asynchronous processing can run longer before there state is dehydrated. Increase the global JTA time-out to 3600 seconds.
WLS Console -> SOADomain -> Configuration -> JTA
BPEL Process Manager
Dehydration store
In high throughput environments, locks can occur in the database that will hold up the BPEL PM from running. This can be improved by increasing the number actions in data block of the database:
- alter table CUBE_INSTANCE initrans 16;
- alter table CUBE_SCOPE initrans 16;
Per domain the threads can be set that are used for synchronous processing (InvokeThreads) and a-synchronous processing (EngineThreads). By default they are
- dspInvokeThreads 20
- dspEngineThreads 30
Note; performance tests should be carried to find the optimal values. This is a best practice recommendation.
Datasources
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 on WLS is 15.
Maximum DB Connections >= For-Each-Domain(dspInvokeThreads + dspEngineThreads)
Increase the maximum value of the data sources:
- jdbc/BPELServerDataSourceWorkflow
- jdbc/BPELServerDataSource
Note: Check also the time-out parameters; Statement Timeout; Maximum Waiting for Connection; Inactive Connection Timeout
Time-out
By default a synchronous process can run for maximum 45 seconds. After this period BPEL PM will mark this instance as failed. Increase this parameter to a higher value. During load test we have seen that this value can be to lows.
Change this time out in the BPEL Admin console.
syncMaxWaitTime 120
BPEL Processes
Any process in the BPEL is dehydrated to the database. There are processes, such as monitoring; auditing or processes that execute simple tasks that are not needed to be dehydrated. This can be achieved by disable dehydration and only dehydrate in case of a failure.
Put in those BPEL process, in their BPEL.XML file the following options:
<configurations>
<property name="inMemoryOptimization">true</property>
<property name="completionPersistPolicy">faulted</property>
<property name="completionPersistLevel">All</property>
</configurations>
Adapters
Make sure that all adapters, database and JMS configuration are using JNDI entries that point to data sources or JMS factories/modules. It is not allowed that they have local connection definitions.
In a cluster environment, you expect that adapters doing the same work on two different nodes might encounter a race condition. So you would like to configure a singleton adapter. This note describes how to do it.
In BPEL.XML file of the polling process:
<activationagents>
<activationAgent className="oracle.tip.adapter.fw.agent.jca.JCAActivationAgent"
partnerLink="JMSRead">
<property name="portType">Consume_Message_ptt</property>
<property name="clusterGroupId">adapterCluster</property>
<property name="clusterAcrossSubnet">false</property>
</activationagent>
</activationagents>
Logging
Reduce the log level in the BPEL console. Most of the logging is set to 'ALL' in this case the default domain, while the Poland domain has the default configuration.
Reducing the logging results in smaller readable log files. If you put everything on ALL, as it is now, you get too much information and some information is only needed for Oracle Support. It is recommended to:
Put everything to INFO
Then set:
default.collaxa.cube.activation DEBUG
default.collaxa.cube.engine.delivery DEBUG
default.collaxa.cube.engine.deployment DEBUG
default.collaxa.cube.services DEBUG
default.collaxa.cube.ws DEBUG
default.collaxa.cube.xml DEBUG
Changes can be applied without restarting the server.
Note: In production environment set the log level to Info and set the audit level to production.
References:
http://download.oracle.com/docs/cd/B31017_01/core.1013/b28942/tuning_bpel.htm
http://orasoa.blogspot.com/2007/01/tuning-bpel-in-nutshell.html
http://download.oracle.com/technology/tech/soa/soa_best_practices_1013x_drop3.pdf
http://puchaanirudh.blogspot.com/2009/01/jvm-tuning-for-soa-suite-applications.html
http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation
http://forums.oracle.com/forums/thread.jspa?messageID=3344909�
http://forums.oracle.com/forums/thread.jspa?threadID=962571
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
