A review: Oracle SOA Suite Best Practice Guide

I read the new Oracle SOA Suite 10.1.3x Best Practices Guide (i wrote a posting as it was released.)

They have collected many tips and tricks, which are very useful for creating applications with BPEL. I want to challenge chapter 9 (Best Practices for a JMS-to-Database Scenario) in this blog.

The focus of this chapter is Oracle SOA Suite Performance. The guide tells us, that this example JMS-to-database is proof-of-concept engagement with a customer.It is an aplication, which receives JMS Messages from a queue and put them after parsing into a database.



To optimize throughput a cluster of 5 servers is used. Two servers do the hosting of the AQ-JMs in an Oracle RAC database, on two servers run the BPEL Process Managers (clustered) and another one which stores the received records in a database. All servers are 2 CPU Opterions (2.1 GHz) with 1-4 GB RAM. All machines are running on Linux.

The configuration of AQ is straight forward. On every RAC node one queue is created with istance affinity to this node. This is the only way to prevent interconnect traffic and contention on the queue. But the hint to tune the parameter aq_tm_processes is not valid anymore (see the Oracle DB documentation)
After reading, that you should use OCI and not thin drivers for the Oracle BPEL Manager, i just have to ask, why OCI is not the default for the SOA Suite installation...

The tuning of the BPEL is quite interesting. They change the asynchronous WSDL with just one input message to a synchronous operation:



and add a dummy reply. But unfortunately the performance enhancement of these changes are not measured, which would be a valuable information....

After some OC4J optimations the measuremnts or better the final number are presented. These final numbers are a little bit disappointing, because nothing is said about how long this measurements where performed. No graphs with rate against a timeline. The problem with performance of database related applications (here AQ-JMS and BPEL schema) is, that you can write very fast into the redo logs but if all logs are busy, the whole system will stall.
But it is like everytime with Oracle: If you know how to tune the database, you are done ;-)