Skip to main content

WSO2 ESB Performance tuning for XSLT transformations

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.


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).


Comments

  1. 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?

    ReplyDelete
  2. Hi Jianbo,
    This 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).

    ReplyDelete

Post a Comment

Popular posts from this blog

WSO2 ESB tuning performance with threads

I have written several blog posts explaining the internal behavior of the ESB and the threads created inside ESB. With this post, I am talking about the effect of threads in the WSO2 ESB and how to tune up threads for optimal performance. You can refer [1] and [2] to understand the threads created within the ESB. [1] http://soatutorials.blogspot.com/2015/05/understanding-threads-created-in-wso2.html [2] http://wso2.com/library/articles/2012/03/importance-performance-wso2-esb-handles-nonobvious/ Within this blog post, I am discussing about the "worker threads" which are used for processing the data within the WSO2 ESB. There are 2 types of worker threads created when you start sending the requests to the server 1) Server Worker/Client Worker Threads 2) Mediator Worker (Synapse-Worker) Threads Server Worker/Client Worker Threads These set of threads will be used to process all the requests/responses coming to the ESB server. ServerWorker Threads will be used to pr...

How puppet works in your IT infrstructure

What is Puppet? Puppet is IT automation software that helps system administrators manage infrastructure throughout its lifecycle, from provisioning and configuration to orchestration and reporting. Using Puppet, you can easily automate repetitive tasks, quickly deploy critical applications, and proactively manage change, scaling from 10s of servers to 1000s, on-premise or in the cloud. How the puppet works? It works like this..Puppet agent is a daemon that runs on all the client servers(the servers where you require some configuration, or the servers which are going to be managed using puppet.) All the clients which are to be managed will have puppet agent installed on them, and are called nodes in puppet. Puppet Master: This machine contains all the configuration for different hosts. Puppet master will run as a daemon on this master server. Puppet Agent: This is the daemon that will run on all the servers, which are to be managed using p...

Understanding Threads created in WSO2 ESB

WSO2 ESB is an asynchronous high performing messaging engine which uses Java NIO technology for its internal implementations. You can find more information about the implementation details about the WSO2 ESB’s high performing http transport known as Pass-Through Transport (PTT) from the links given below. [1] http://soatutorials.blogspot.com/2015/05/understanding-wso2-esb-pass-through.html [2] http://wso2.com/library/articles/2013/12/demystifying-wso2-esb-pass-through-transport-part-i/ From this tutorial, I am going to discuss about various threads created when you start the ESB and start processing requests with that. This would help you to troubleshoot critical ESB server issues with the usage of a thread dump. You can monitor the threads created by using a monitoring tool like Jconsole or java mission control (java 1.7.40 upwards). Given below is a list of important threads and their stack traces from an active ESB server.  PassThroughHTTPSSender ( 1 Thread ...