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.
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:
And finally, this is the mule flow that was tested:
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:
Again, 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?
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.
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!