Check out the new guide on SOA 11g Performance Tuning published July 2013 by Packt and written by Oracle Partner C2B2 Consulting Ltd:
See more details here: http://www.packtpub.com/oracle-soa-suite-11g-performance-tuning-cookbook/book
From a first glimpse myself I have the following impressions:
- The book gives a very good overview of the various topics of Performance Tuning
- A lot of recommendations are very valuable and show that the authors have real project experience
- My feeling is though that it concentrates a little bit too much on the low level infrastructure (like JVM tuning) and its config settings instead of explaining the why and what to tweak. Example: reducing audit level may help – but can also impact monitoring capabilities during production.
- Even though it touches database tuning, the book underestimates the need of database performance monitoring, database tuning, of regular purging and of tuning to prevent data growth. This often is a major area which leads to performance problems if not addressed in an early stage. For example no word about using Secure File LOBs for reducing HW contention in the DB….
- Architectural decisions are not mentioned– like splitting up one SOA domain into multiple ones for various reasons.
- SOA monitoring chapter promotes and focuses Hyperic as a product and misses out Oracle Grid Control and other available solutions.
- Design-level tuning covers only BPEL. Often one key area of performance tuning is to choose the right SOA component for a requirement. For example to use OSB
- A few components are not covered, for example Mediator resequencer, OHS tuning, XREFs and DVMs.
For some recommendations however, you should be careful to follow them without validation. Just one example:
“The adapter.jms.receive.threads, adapter.aq.dequeue.threads, and InboundThreadCount properties set the number of threads available for processing JMS,
AQ, and MQ messages. The default value for these is 5, and performance can be improved by using more threads to dequeue messages from these providers.”
First, the default for “adapter.jms.receive.threads” is 1. Secondly, as an experience from real world complex deployments in large clusters, the right number of consumers should be determined by the expected load and for example the message size (potentially triggering different transaction times). Last but not least, in a cluster, each JMS consumer thread is multiplied by the number of cluster nodes. Therefore you should be very careful to increase JMS Adapter receive threads. I have seen performance tests where we proved that throughput increased dramatically by decreasing the number of JMS receive threads…
As a summary, the book provides some good add on’s to the standard documentation available in the Oracle Fusion Middleware Performance and Tuning Guide.
Get a copy, check them out and tune your SOA 11g environment!