XSLT transformations: also faster since Mule 3.6

motif

speed

This is a follow up to the last post in which we discussed performance improvements on our XPath functionality obtained from the revamped XPath and XSLT support in 3.6. This time, we’ll go through the same exercise but for the use case.

The test

Just like with , we worked with Luciano Gandini from the performance team. He came up with a test in which he measures the transactions per second (TPS) and latency of two XSLT transformations which inverts the tags of an XML.

This is what the two XSLT files looks like:

And finally, this is the mule flow that was tested:

The Results

Let’s analyze the results starting from a TPS point of view:
image (4)

When tested with few , the performance is pretty much the same. However, as we started increasing the concurrency level, then the performance climbed up to 50% faster than the same transformation running un Mule 3.5.2.

The first conclusion is that concurrency is a factor here. So let’s take a look at the latency:

imageAgain, latency stays pretty much the same until the concurrency starts to climb, reaching an average of 30% less latency once concurrency went past 50 threads. So the question was, what happens if we give it even more concurrency?

image (1)

Hitting the flow with more than 1000 concurrent threads showed pretty much the same behavior as before, until at some point the lines began to converge. This comes as no surprise since – as we always say in all the performance related posts – less threads are often more.

Summary

Just as with XPath, XSLT also got a performance boost in the 3.6 release. However, this improvement only gets considerably noticeable in cases of high concurrency.

Thank you for reading!

 


We'd love to hear your opinion on this post