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.
