SOA Suite Performance – Don’t fight against the machine - Part 1

Performance optimization on SOA Suite applications is a challenge! After about one and a half years of performance tuning activities on a large SOA Suite project I’m fully confident to make such an assertion. Why is it so difficult to tune the performance, because the performance is depended on several system architecture layers.


On top of the stack JDeveloper developed applications/services running on the SCA Container. Design and configuration on SCA Composite and SCA Component level have a critical influence on the success of performance optimization activities. Below the SCA Application layer we have the FMW Common Infrastructure (e.g., JRF, OWSM, EM Fusion Control) together with the SOA Suite Service Engines (e.g. BPEL, Mediator) as SCA Runtime environment SOA Infra. There are many performance relevant tweaks you could do on the SOA Infra layer. The Oracle Weblogic Application Server is the foundation on which all Java EE-based Oracle FMW components are build. Classic techniques on JEE performance optimization are used together with the possible utilization of the Coherence Data Grid. JVM optimization is also well known but its performance essential to have the right GC strategy with the right parameterization. Below the JVM we will have the layer with the Operating System which could run on a Hypervisor. Both are highly critical on resource allocation and therefore important on performance tuning activities. As an Application Architect you have to trust the Infrastructure Experts doing their best on performance tuning because in most cases you are leaving your knowledge domain.

Down below you have the machine hardware with network and storage. Here you will find your “physical” limitations. The machine is coming with a certain numbers of CPU/cores, clock speed and the size of the internal memory cache of the system CPU(s). You will have a certain speed and width of the system’s address and data buses. And you will be limited by the amount of memory, the width of its data path and the memory access time which causes the CPU(s) to wait for memory. And you will be highly depended on the speed of the I/O devices such as network and disk controllers.

These hardware factors have the greatest influence on the application performance. For example, Oracle SOA Suite architectures will have CPU-intensive operations happening in a single thread for components like rule evaluation and XML processing. Therefore the CPU clock speed is an important factor to consider. There will come a time during your performance optimization activities when, despite all tuning activities on the upper architecture system layers, you have to add more powerful hardware or upgrade the existing hardware. If you miss the right time to scale up and to scale out, the application architecture will become out of balance on the non-functional system qualities by focusing too much on the performance aspect on the SCA application layer. And because you have the design freedom ugly compromise are make for reaching the right performance. Clearness and comprehensibility of the architecture, extensibility, reusability and maintainability are system qualities which will suffer as a result. System architects are also talking of increasing system entropy (disorder). Furthermore the relationship on costs of the performance tuning activities and the purchase of hardware is at a certain point of time no longer reasonable.  

When you start to reduce your SCA Composite modularization on performance reasons, when you realize that your BPEL processes are getting monolithic and you are doing BPEL programming in small, when you don’t mediate on inbound and outbound interfaces because of performance reasons you will have on indicator that it’s time to scale up and to scale out.

Note: Don’t fight for last possible amount of performance on the SCA application layer. You should realize when the right time has come to throw in the towel. Don’t be naïve and believe that all performance problems could be solved on the layers above the machine.

If you have online and batch processing you should also consider to have an own Weblogic Cluster running SOA Suite for online processing and an own Weblogic cluster for batch processing. This is an important consideration because the configuration on the layers will differ between an online and batch related configuration. That’s something we will examine on the next blog when we take a detailed look on the JVM.