WSO2 ESB is the world's fastest open source ESB. This has been proved with the latest round of performance test done by WSO2. You can find the results on this test from the below link.
http://wso2.com/library/articles/2014/02/esb-performance-round-7.5/
Above results are achieved by tuning the WSO2 ESB for a high concurrent production environment. Performance tuning for the WSO2 ESB server can be found in the below link.
http://docs.wso2.com/display/ESB481/Performance+Tuning
Let's think that now you have gone through the performance test and tuned the WSO2 ESB according to the above guide. Now you are going to implement your business logic with the synapse configuration language and various extension points provided by the WSO ESB. This blog post will give you some tips and tricks to achieve optimum performance from WSO2 ESB by carefully implementing your business logic.
Accessing properties within your configuration
properties are a very important elements of a configuration when you develop your business logic using synapse configuration language. In most of the implementations, we set properties at some place and retrieve those properties at a different instance of the mediation flow. When you are retrieving properties, you can use the below mentioned two methods to retrieve properties which are defined in your configuration.
1. using xpath extension functions
get-property("Property-Name") - properties defined in synapse (or default) scope
2. using synapse xpath variables
$ctx:Property-Name
From the above two methods, second method provides the optimum performance. It is always recommended to use that approach whenever possible. You can access properties defined at different scopes using the above method.
$ctx:Property-Name (for synapse scope properties)
$axis2:Property-Name (for axis2 scope properties)
$trp:Property-Name (for transport scope properties)
$body:Property-Name (for accessing message body)
$Header:Property-Name (for accessing SOAP headers)
Always check for log enability before executing any log printing statement
When you are writing class mediators, you will always use log statement for debugging purposes. For example let's say you have the below log statement in your class mediator.
Log.debug("This is a debug log message" + variable_name + results);
Once you have this code and run this code in the WSO2 ESB using a class mediator, unless you enable debug logging for your class, this log will not get printed. But the drawback of the above approach is even though it is not getting printed, it will execute the string concatenation given as the parameters to the log method. This is a heavy string operation which uses StringBuffers internally by JVM and may cause performance issues if you have a lot of these statements. Therefore, to achieve the optimal performance while having your logging as it is, you need to check for the logging enability before executing this statement as below.
if(Log.isDebugEnabled())
{
Log.debug("This is a debug log message" + variable_name + results);
}
It is always better to check the condition before executing any logging message in your mediator source code.
Always use FastXSLT mediator instead of default XSLT mediator wherever possible for high performance implementations
Another important part of any implementation would be the transformation of messages in to different formats. You can use several mediators to do your transformation. If it is a simple transformation, then you can use
1. enrich mediator
2. payloadFactory mediator
If it is a complex transformation, you can use
1. XSLT mediator
2. FastXSLT mediator
from the above two options, FastXSLT is much more performance improved than the XSLT mediator. If you cannot achieve your transformation with the FastXSLT, then it is a good idea to write a custom class mediator to do your transformation since it is much faster thatn XSLT mediator.
Comments
Post a Comment