This blog post is a continuation of my performance tuning article series which you can find in this blog site. Today I will be talking about one of the heavily used component of the WSO2 ESB and how to tune the performance of ESB for transformation use cases.
When we are doing transformation within ESB, we can use XSLT or FastXSLT mediators for doing complex transformations. The FastXSLT Mediator is similar to the XSLT mediator, but it uses the Streaming XPath Parser and applies the XSLT transformation to the message stream instead of to the XML message payload. The result is a faster transformation, but you cannot specify the source, properties, features, or resources as you can with the XSLT mediator. Therefore, the FastXSLT mediator is intended to be used to gain performance in cases where the original message remains unmodified. Any pre-processing performed on the message payload will not be visible to the FastXSLT mediator, because the transformation logic is applied on the original message stream instead of the message payload. In cases where the message payload needs to be pre-processed, use the XSLT mediator instead of the FastXSLT mediator.
Here is a performance comparison of the performance of XSLT and FastXSLT mediators.
According to the above results, you can clearly say there is a huge performance improvement with the FastXSLT mediator. You can enable FastXSLT mediator by adding the following configurations to your ESB.
To enable the FastXSLT mediator, your XSLT script must include the following parameter in the XSL output.
omit-xml-declaration="yes"
eg: <xsl:output method="xml" omit-xml-declaration="yes" encoding="UTF-8" indent="yes"/>
All is good if you are not doing any payload processing before the XSLT transformation. But in reality, you may find use cases where you do pre-processing before doing the actual message transformation using XSLT mediator.
If you look at the above results, it is bit worrying if you cannot use FastXSLT mediator. Because it has very low numbers for XSLT mediator when the message size is large (105k). In the next section, I will talk about how to tune up the performance of the XSLT mediator itself.
In the XSLT mediator, WSO2 ESB is using two parameters to control the memory usage of the the server. These two parameters can be configured in synapse.properties file as mentioned below.
synapse.temp_data.chunk.size=3072
synapse.temp_data.chunk.threshold=8
The above parameters decide when to write to file system when the message size is larger. The default values for the above parameters will allow WSO2 ESB to process messages with the size 3072*8 = 24K with the XSLT mediator without writing to the file system. Which means, there will not be any performance drop in the XSLT mediator when the message size is less than 25K. But when the message size is 105K, you can see clear performance degradation.
105k 285.97 25.78
We can improve the performance of the XSLT mediator by allowing more memory to use when processing large messages with XSLT mediator by configuring the parameters as mentioned below.
synapse.temp_data.chunk.size=16384
synapse.temp_data.chunk.threshold=32
With the above parameters, XSLT mediator can process messages upto 16K*32 = 512K without writing to file system. With the above configuration in place, here are the results.
When we are doing transformation within ESB, we can use XSLT or FastXSLT mediators for doing complex transformations. The FastXSLT Mediator is similar to the XSLT mediator, but it uses the Streaming XPath Parser and applies the XSLT transformation to the message stream instead of to the XML message payload. The result is a faster transformation, but you cannot specify the source, properties, features, or resources as you can with the XSLT mediator. Therefore, the FastXSLT mediator is intended to be used to gain performance in cases where the original message remains unmodified. Any pre-processing performed on the message payload will not be visible to the FastXSLT mediator, because the transformation logic is applied on the original message stream instead of the message payload. In cases where the message payload needs to be pre-processed, use the XSLT mediator instead of the FastXSLT mediator.
Here is a performance comparison of the performance of XSLT and FastXSLT mediators.
| Message size | Average response time(ms) | Average TPS | CPU % | Concurrency | |||
| XSLT | FastXSLT | XSLT | FastXSLT | XSLT | FastXSLT | ||
| 8k | 14.76 | 6.34 | 550 | 610 | 70 | 60 | 50 |
| 8k | 52.74 | 20.68 | 775 | 1035 | 75 | 75 | 100 |
| 8k | 104.16 | 50.37 | 825 | 1177 | 90 | 85 | 150 |
| 105k | 285.97 | 25.78 | 14 | 49 | 90 | 50 | 5 |
| 105k | 611.74 | 36.26 | 15 | 88 | 100 | 70 | 10 |
| 105k | 946.63 | 48.37 | 15 | 121 | 100 | 80 | 15 |
According to the above results, you can clearly say there is a huge performance improvement with the FastXSLT mediator. You can enable FastXSLT mediator by adding the following configurations to your ESB.
Add the following parameter to enable streaming XPath in <ESB_HOME>/repository/conf/synapse.properties file. For example:
synapse.streaming.xpath.enabled=true
synapse.temp_data.chunk.size=3072
To enable the FastXSLT mediator, your XSLT script must include the following parameter in the XSL output.
omit-xml-declaration="yes"
eg: <xsl:output method="xml" omit-xml-declaration="yes" encoding="UTF-8" indent="yes"/>
All is good if you are not doing any payload processing before the XSLT transformation. But in reality, you may find use cases where you do pre-processing before doing the actual message transformation using XSLT mediator.
If you look at the above results, it is bit worrying if you cannot use FastXSLT mediator. Because it has very low numbers for XSLT mediator when the message size is large (105k). In the next section, I will talk about how to tune up the performance of the XSLT mediator itself.
In the XSLT mediator, WSO2 ESB is using two parameters to control the memory usage of the the server. These two parameters can be configured in synapse.properties file as mentioned below.
synapse.temp_data.chunk.size=3072
synapse.temp_data.chunk.threshold=8
The above parameters decide when to write to file system when the message size is larger. The default values for the above parameters will allow WSO2 ESB to process messages with the size 3072*8 = 24K with the XSLT mediator without writing to the file system. Which means, there will not be any performance drop in the XSLT mediator when the message size is less than 25K. But when the message size is 105K, you can see clear performance degradation.
105k 285.97 25.78
We can improve the performance of the XSLT mediator by allowing more memory to use when processing large messages with XSLT mediator by configuring the parameters as mentioned below.
synapse.temp_data.chunk.size=16384
synapse.temp_data.chunk.threshold=32
With the above parameters, XSLT mediator can process messages upto 16K*32 = 512K without writing to file system. With the above configuration in place, here are the results.
| Message size | Average response time(ms) | Average TPS | CPU % | ||||||
| XSLT | XSLT-32k-Buffer | FastXSLT | XSLT | XSLT-32k-Buffer | FastXSLT | XSLT | XSLT-32k-Buffer | FastXSLT | |
| 105k | 285.97 | 53.7 | 25.78 | 14 | 39 | 49 | 90 | 50 | 50 |
| 105k | 611.74 | 75.59 | 36.26 | 15 | 66 | 88 | 100 | 70 | 70 |
| 105k | 946.63 | 115.98 | 48.37 | 15 | 78 | 121 | 100 | 80 | 80 |
With the above results, we can clearly see that performance of XSLT mediator has been improved by more than 500%.
You can configure the above parameters according to your message sizes and observe massive performance improvements with the XSLT mediator (also for FastXSLT mediator).
Hi, Chanaka, thanks for sharing these performance stats for WSO2 ESB XSLT/FastXSLT mediators. Can you please share the server and JVM configuration used for your benchmark testing?
ReplyDeleteHi Jianbo,
ReplyDeleteThis test has been carried out in my development machine which 4core 8GB machine with default JVM configurations which are there in ESB vanilla pack (1GB of heap space).