Once you are comfortable with developing and deploying applications in OSB, the next thing that comes for you will be how fast you can run your applications and what are the standard procedures that need to be followed up in order to achieve that.
Based on my experience, I have come up with few points which will help you fine tune your applications and get good response times. The fine tuning of any application should start from the design phase. The design can be high level design, deployment design, low level design and finally the standard way of implementing these things.
High level design
One should follow the most suitable and efficient design pattern in-order to achieve good result. Considering different solutions for the same problem will be handy.
Deployment design & Server Configuration
OSB applications runs on Weblogic Server, a J2EE application server. So you should be very careful while selecting the JVM parameters like heap memory, gc algorithm, nursery size and other Java options.
Deep level analysis need to be done in order to understand whether the application that you are building is CPU intensive or memory intensive.
Low level design
This is nothing but the proper work flow pattern design. You should analyse which work flow pattern will be more efficient in terms of number of threads it creates, the memory utilization and CPU utilization. Also how much of static data need to be handled and how it should be cached and so on.
Best practices for developing highly efficient OSB applications.
1. Cache the static data that need to be configured in your application. You need to consider the below points
a. how much of data need to be cached
b. Which caching api to use.
There are two popular caching api's available - Java Caching System (JCS) and Oracle Coherence caching which Oracle recommends.
This is a simple caching scheme where the static data will be cached per server. This can be easily integrated to OSB application and the complexity is very less. But this is not suitable for caching very large amount of data. The caching mechanism may fail under heavy load and the cached data over 50 rows from a table.
Oracle Coherence Caching
This is the Oracle recommended caching mechanism. We need to configure the coherence cluster in the Weblogic server level in order to use this. This is very robust and stable cache mechanism which can handle heavy load and large amount of data. The cached data will be available through out the cluster. There are different methods available for clearing the Coherence cache.
2. Disable all tracing
For high end performance , you need to disable all kinds of tracing. This can be easily done in sbconsole.
sbconsole -> smart search
If you are using coherence caching, make sure that you enable caching for the business service used for that.
3. Datasources
If you are using datasouce for select or query operations, then use non-XA driver.
4. XQuery tuning
a. Avoid using '//' anywhere in the xquery
b. use indexes for faster xquery parsing.
c. Use FLOWR expressions instead of 'if' conditions for checking the existence of any tag.
d. If you want to use any intermediate xpath continuously , then assign that to a variable
and use it rather than querying it multiple times.
e. Using indexes for xqueries, if you are not sure that it will return multiple rows
f. If you use multiple 'let' statements, group it under one 'let'
g. Avoid declaring the namespaces above xquery, it will lead to different namespace
prefixes during runtime. Instead put it inline with xquery xml tags.
h. Avoid using of '*' to the maximum extend
i. Split large sized dbquery xmls to multiple parts so that xquery parsing will be easy.
Design the dbentries in such a way that you would be easily able to split with
respect to some parameters.
j. Reduce the number of parameters passing to the XQuery. Instead you can pass a single
xml which will have all the parameters mapped
Xquery Performance testing guidelines
1. Test with huge payloads
2. Testing with values inside payload in different order (better reverse the order in the payload and test)
For any queries , please drop a mail to
sajurrk@gmail.com or saju_rrk@yahoo.com
Based on my experience, I have come up with few points which will help you fine tune your applications and get good response times. The fine tuning of any application should start from the design phase. The design can be high level design, deployment design, low level design and finally the standard way of implementing these things.
High level design
One should follow the most suitable and efficient design pattern in-order to achieve good result. Considering different solutions for the same problem will be handy.
Deployment design & Server Configuration
OSB applications runs on Weblogic Server, a J2EE application server. So you should be very careful while selecting the JVM parameters like heap memory, gc algorithm, nursery size and other Java options.
Deep level analysis need to be done in order to understand whether the application that you are building is CPU intensive or memory intensive.
Low level design
This is nothing but the proper work flow pattern design. You should analyse which work flow pattern will be more efficient in terms of number of threads it creates, the memory utilization and CPU utilization. Also how much of static data need to be handled and how it should be cached and so on.
Best practices for developing highly efficient OSB applications.
1. Cache the static data that need to be configured in your application. You need to consider the below points
a. how much of data need to be cached
b. Which caching api to use.
There are two popular caching api's available - Java Caching System (JCS) and Oracle Coherence caching which Oracle recommends.
Java Caching System (JCS)
This is a simple caching scheme where the static data will be cached per server. This can be easily integrated to OSB application and the complexity is very less. But this is not suitable for caching very large amount of data. The caching mechanism may fail under heavy load and the cached data over 50 rows from a table.
Oracle Coherence Caching
This is the Oracle recommended caching mechanism. We need to configure the coherence cluster in the Weblogic server level in order to use this. This is very robust and stable cache mechanism which can handle heavy load and large amount of data. The cached data will be available through out the cluster. There are different methods available for clearing the Coherence cache.
2. Disable all tracing
For high end performance , you need to disable all kinds of tracing. This can be easily done in sbconsole.
sbconsole -> smart search
If you are using coherence caching, make sure that you enable caching for the business service used for that.
3. Datasources
If you are using datasouce for select or query operations, then use non-XA driver.
4. XQuery tuning
a. Avoid using '//' anywhere in the xquery
b. use indexes for faster xquery parsing.
c. Use FLOWR expressions instead of 'if' conditions for checking the existence of any tag.
d. If you want to use any intermediate xpath continuously , then assign that to a variable
and use it rather than querying it multiple times.
e. Using indexes for xqueries, if you are not sure that it will return multiple rows
f. If you use multiple 'let' statements, group it under one 'let'
g. Avoid declaring the namespaces above xquery, it will lead to different namespace
prefixes during runtime. Instead put it inline with xquery xml tags.
h. Avoid using of '*' to the maximum extend
i. Split large sized dbquery xmls to multiple parts so that xquery parsing will be easy.
Design the dbentries in such a way that you would be easily able to split with
respect to some parameters.
j. Reduce the number of parameters passing to the XQuery. Instead you can pass a single
xml which will have all the parameters mapped
Xquery Performance testing guidelines
1. Test with huge payloads
2. Testing with values inside payload in different order (better reverse the order in the payload and test)
For any queries , please drop a mail to
sajurrk@gmail.com or saju_rrk@yahoo.com
