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:
The Results
latest report
Learn why we are the Leaders in API management and iPaaS
Let’s analyze the results starting from a TPS point of view:
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.
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.
