Reading Time: 3 minutes

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 Mule 3.6. This time, we’ll go through the same exercise but for the XSLT use case.

The test

Just like with XPath, 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:

Could not embed GitHub Gist e7db7956c68402bf6238: API rate limit exceeded for 34.66.93.163. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
Could not embed GitHub Gist d938a04981658c46132c: API rate limit exceeded for 34.66.93.163. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)

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

Could not embed GitHub Gist 10dcaec34965468f8933: API rate limit exceeded for 34.66.93.163. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)

The Results

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

When tested with few threads, 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!