SOA Suite 11g --> Performance Tuning Part1

Scenario- we have a SOA composite that includes a synchronous BPEL process that calls a stateless session EJB (transferFundsBean) to transfer funds from account A to account B. So essentially a synchronous/transient process. The composite itself is exposed via an EJB Service interface.

We can tune on different levels -

• EJB - transferFundsBean




• BPEL




• SOA Suite




• WLS




• JVM




• O/S

EJB tuning

Avoid, if possible, using the RequiresNew transaction parameter - ours is set to Required.

We can pre-load the bean pool by amending the weblogic-ejb-jar.xml




max-beans-in-free-pool
should be set equal to the number of threads expected to invoke the EJB concurrently

initial-beans-in-free-pool
the cost of creating EJB instances is not incurred at run time


You can then monitor the Bean activity using WLS console.



I customized the table and added the Miss Total Count. This will show if my pool settings are adequate to cope with the loads I expect.

BPEL App Tuning
I added the following to the composite.xml -



SOA Server Tuning



Turning these off increases performance, but it does mean one doesn't see any instance results in the em console.



We assume that the only interesting one for us, as this is a SYNCHRONOUS process, is Dispatcher Invoker Threads.

However we also assume that, in our scenario, the EJB client thread executes the instance, thus bypassing these thread settings.

WLS Tuning

A possible issue here for us is JTA timeouts when running large performance tests.
So we increased the timeout setting appropriately.






JVM Tuning

For this exercise we are using JRockit.

Heap Size

According to the doc -
"A large heap decreases the garbage collection frequency but may take slightly longer to garbage collect. Typically a heap should be at least twice the size of the live objects in the heap, meaning that at least half of the heap should be freed at each garbage collection. For server applications you can usually set the heap as large as the available memory in your system will allow, as long as this doesn’t cause paging."

We began by setting the min/max heap size to 4GB.

Garbage collection
We stayed with the default here -

We have 3 alternatives -

throughput - optimizes garbage collection for application throughput (default)
pauseTime - optimizes garbage collection for short garbage collection pauses
deterministic - optimizes garbage collection for very short and predetermined garbage collection pauses(requires JRockit realtime)

Nursery Size
We didn't adjust this but it may be interesting for some applications.
Again to quote the official docc -

"The nursery is an area of the heap where new objects are allocated. When the nursery becomes full it is garbage collected separately in a young collection. The frequency and duration of young collections is determined by the nursery size. A large nursery decreases the frequency but the duration of each young collection might increase.

The nursery size is adjusted automatically to optimize for application throughput if you use the -Xgc:throughput or -Xgc:genpar option. Typically, the nursery size should be as large as possible while maintaining short young collection pauses. Depending on the application, a nursery size can be anything from a few megabytes up to half of the heap size."

I strongly suggest you use JRockit Mission Control to check on what's happening during your tests.



Also, if you think you are having thread contention issues, you can do a thread dump directly from the WLS console.