Book review- Oracle SOA Suite 11g Performance Tuning Cookbook

This book covers almost all aspects of the performance tuning starting from the weblogic server to different SOA components. The highlight being detailed steps on different options available to analyze and troubleshoot the issues.

The modularization of the book is really good. The book starts with the soa infrastructure, listing the different options of monitoring the JVM’s, SOA suite and different components like bpel, rules, mediator which are actually really good. BPEL and BPMN tuning tips are already available as part of the performance guides/blogs ,but the authors have captured that as well in this book, which is good in one way so as it helps to bring all the performance tuning options together. Monitoring SOA suite, JVM Garbage collections, Platform tuning are very well covered in the book.  It was good to learn we could leverage multiple available options mentioned in the book  to monitor/troubleshoot different JVM/server issues.

          The book also covers the tuning aspects from process perspective as well as at environment level with equal importance. I recommend this book as a must read for SOA server Administrators as well as SOA Consultants, this book will help you to get most out of the SOA infrastructure. The book will make an interesting read for those people who love to take it the next level.

Link to the book @ http://bit.ly/12lrajU

Cook book on Oracle SOA Suite 11g Performance Tuning

Currently reading a cook book on Oracle SOA Suite 11g Performance Tuning by Matt Brasier, Nicholas Wright. Interesting read as it brings together all the performance tuning/monitoring options under one roof. You can get it @ http://bit.ly/12lrajU

B2B performance issues due to large payloads

My customer was having performance issues while processing big payloads in B2B.  The problem was that the B2B server was hanging whenever a large payload was getting processed at B2B gateway.  The customer wanted a resolution to this problem..

Analysis

-------------------

Whenever Oracle B2B is processing an EDI file, it stores EDI payload and XML file in lob segment in B2B_DATA_STORAGE table. For big files this log segment grows significantly and create b2b runtime problem.The server hangs due to this background process.

Solution

----------------------

Oracle B2B has largepayload support, in which payload will not get persisted in DB.’

Please refer B2B Documentation for more details

http://docs.oracle.com/cd/E14571_01/integration.1111/e10229/app_perform.htm#BABIEJJE

Inbound Setup

-----------------

 Large Payload Size is the property that needs to be set for inbound cases. 

Go to Administration > Configuration.

If a composite is deployed to handle the large payload, this is the only configuration needed. If B2B is not delivering the payload to a composite, set Use JMS Queue as default to true

 Go to Administration > Configuration.

With Use JMS Queue as default set to true, the payload is delivered to B2B_IN_QUEUE, a JMS-based queue.

Hope this helps

Processing huge payload using fusion middleware

One of the main design requirements is to baseline the expected volume of data flowing through the middleware layer. Recently one of my clients asked me to review the design of some interfaces which were failing the load testing and was not able to pass the peak volume testing . They had issues of server crashing and JVM out of memory errors. On analysis the peak volumes were quite huge for these interfaces to handle. The payload file size used to touch a peak of 25 mb. As per the design the process used to receive the XML payload as a string, which when get converted to a variable and transformed used to clog the heap space which may finally result in running out of heap space(JVM).

There were multiple options which came to the table. I am listing a few of them

1. split the payload into smaller chunks before feeding it to the BPEL process and process it one by one.

+ve--> The BPEL process will be left untouched as flow will be same as the payload size will be manageable.

-ve -->There will be more additional components which will be performing the splitting of payload into smaller chunks. The more components involved adds to more points of exception handling.

-ve --> The overhead of maintaining the atomicity of the transactions are too high and it would complicate the entire system

-ve --> In case process uses control tables it will involve multiple calls to control tables which would maintain the entire end to end processing of the document.

2. To go for a complete java alternative which will be parsing the XML file and converting it into JAVA POJO's and directly inserting into database or writing to a file.

+ve --> Stable since it XML parsers and java option is tried and tested option.

-ve --> Moving away from the common architecture of using middleware components of BPEL ,ESB to more conservative approach.

3. To parse the XML document in smaller chunks in XSL transformation so that we directly address the clogging of heap space due to transformation of XML document. The option was to process smaller chunks of the document within a while in the BPEL process.

+ve--> The process will have better end to end control as the while loop is within and will be able to use all the transaction management capabilities with BPEL to maintain the atomicity of the transaction.

-ve --> In case process uses control tables it will involve multiple calls to control tables which would maintain the entire end to end processing of the document.

The 3rd option is the best work around to handle the huge payload transformation and design issues. The huge payload was processes successfully and it passed the negative and load testing with flying colours.