Wednesday, March 28, 2007

XSLT via Smooks - Comparisons

As you may already know, JBoss ESB uses Smooks to perform message transformation. One of the design goals of Smooks is to support fragment based transformations i.e. targeting transformation logic at a fragment of an XML message/document as opposed to the whole message. The good thing about this approach is that it not only means you can perform more componentization of your transformation logic, but it also means (often more importantly) that you can easily mix and match different types of transformation logic (XSLT, Java, Groovy, StringTemplate etc) within the context of a single message transformation. This is a very powerful feature. From a purely XSLT perspective, this also means you can have functionality equivalent to XSLT Extensions (Xalan Extensions), but maintain portability across XSL Processors.

I recently performed some performance profiling of Smooks based XSL transforms, comparing them against standalone XSLT. This was done in order to get a better idea of the overhead incurred by using Smooks to perform XSL based transforms. I'll attempt to answer the question of why you'd bother applying XSLT via Smooks in future blog.

The comparisons were run on a Dell Latitude D820 (2GHz Dual Core), 2 GB of RAM, running Windows XP, running jdk1.5.0_10.

For this round of comparisons (I hope to do more some time in the future):
  1. I selected a very simple message format (an with multiple ), as well as a very simple set of XML to XML transformations to be performed on that message. I wanted to keep it simple in order to keep the resulting XSLTs as simple as possible. This way I hope I can get a "worse case scenario" re the overhead incurred while using Smooks to perform XSL transforms. The tests are available here.
  2. I compared the number of messages transformed in a 6hr time period.
  3. I compared the results produced by using the following XSLT processors: Sun XSLTC (JDK 1.5), Xalan 2.7.0, Saxon 8.7.
  4. I compared the results produced by a DOM Source and Result for XSLT Standalone versus a DOM Source and Result on Smooks.
  5. I compared the results produced by streaming both the Source and Result for XSLT Standalone versus a DOM Source and Result on Smooks (Smooks only supports DOM based XSLT).
  6. I tested against 10 input messages ranging in size from 20K to 200K. That is, 10 threads running concurrently, continually transforming, each pausing for 10ms between iterations.
  7. The message bytes were read and buffered in memory so as to avoid File IO variabilities.
  8. During the timed test runs, I didn't compare the transformation output against the expected output. However, I did perform preliminary test runs on all processors and verified that the output produced across the board was consistent. The one exception to this was Xalan 2.7.0, which has a concurrency bug that results in the transformed output not being consistent when the XSL is not applied in a synchronized fashion. I still ran the tests against Xalan unsynchronized, so as to get an idea of how it would perform, assuming the absence of this bug.
The test results (listed below) clearly show that streaming XML into an XSL processor makes a huge difference in terms of throughput. The fact that streaming is faster did not surprise me, but the extent of the difference did. In some cases the whole process (taking the input stream, transforming it and producing the output stream) was up to 4 times faster than the poorest performing alternative (taking the input stream, paring it to a DOM, transforming the DOM to a DOM using the XSL Transformer and finally serializing the resulting DOM to the output stream).

In summary, the performance figures are as follows....

DOM based XSLT Vs Smooks based XSLT (also DOM based):



Total Bytes - XSLTTotal Bytes - Smooks/XSLTSmooks Relative Performance
Sun XSLTC709530946565995260892884.50%
Saxon 8.7319880472482987463103293.39%
Xalan 2.7.0400900381203857131051296.21%




(full details)

Stream based XSLT Vs Smooks based XSLT (DOM based):



Total Bytes - XSLTTotal Bytes - Smooks/XSLTSmooks Relative Performance
Sun XSLTC2237761892165995260892826.79%
Saxon 8.71464828944402987463103220.39%
Xalan 2.7.0863166141363857131051244.69%




(full details)

To understand what this means for JBoss ESB Transformation, you first need to understand what it means for Smooks. At the top of this blog I mentioned how Smooks implements a fragment based approach to message transformations (including some of advantages of that approach). The down side to this fragment based approach is that Smooks currently supports this via a DOM based model.

So what does all this mean for JBoss ESB Transformation. Well, because JBoss ESB Transformation relies on Smooks to manage and apply transformation logic (including XSL transforms), it means that JBoss ESB cannot currently avail of the performance advantages offered by streaming messages into an XSL Processor. So, for a transformation where you don't need to features offered by Smooks (fragment based transforms etc) and you want to implement the transformation in XSLT, the performance hit is quite significant.

Luckily, this is not all that difficult to work around for JBoss ESB because we can simply implement a native XSLT ActionProcessor that can apply XSLTs using streaming. This is just a couple of lines of code - no big deal. From a Smooks perspective, there's a little bit more involved, but I don't think all that much. In short, Smooks could simply check the resources targeted at the message exchange in question, and if there's only one, which is targeted at the "docroot" fragment, and it's a stream supporting resource, then stream it - no need to DOM'ify. This would enable JBoss ESB to have the best of both worlds again... stream based XSLT + management and exchange based selection of transformation resources (via Smooks). We'll keep this for another blog :-)

6 comments:

ert said...

Ha! I beat Mark to leaving the first comment. Nice read Tom. I really like the fragment approach, having written some huge XSLTs in the past. I think one of the most attractive benefits for me is re-using the fragments in other transformations. That could have saved me a lot of time. I'd like to see a "best-case-scenario" test where the XLST gets really hairy, i.e. due to lots of normalization in the XML which makes you have to loop and jump, as that would be much easier to implement (and probably better performing) using Smooks. Maybe we can do this for a real world scenario, if any of our users is interested in some transformation optimization.

Another thought I had that fragment processing may lend itself better to utilize the power of multiprocessor machines?

Tom Fennelly said...

Sure thing Kurt.... comparisons based on a more complex transformation scenario are something I do plan on doing.

As I said, I purposely chose the message format and transformation so as to favor XSLT. Any XSLT processor should be able to perform that transform in a single pass.

As the transformation gets more hairy, I'd expect the advantages of streaming the message to fall off - I've yet to prove that more formally however :-)

The streaming approach also has the downside of it being a one-shot-transformation-solution. You need to be able to do all your transformation within a single application of the XSLT.

Anonymous said...

情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣,情趣,情趣,情趣,情趣,情趣,情趣用品,情趣用品,情趣,情趣,A片,A片,情色,A片,A片,情色,A片,A片,情趣用品,A片,情趣用品,A片,情趣用品,a片,情趣用品

A片,A片,AV女優,色情,成人,做愛,情色,AIO,視訊聊天室,SEX,聊天室,自拍,AV,情色,成人,情色,aio,sex,成人,情色

免費A片,美女視訊,情色交友,免費AV,色情網站,辣妹視訊,美女交友,色情影片,成人影片,成人網站,H漫,18成人,成人圖片,成人漫畫,情色網,日本A片,免費A片下載,性愛

情色文學,色情A片,A片下載,色情遊戲,色情影片,色情聊天室,情色電影,免費視訊,免費視訊聊天,免費視訊聊天室,一葉情貼圖片區,情色視訊,免費成人影片,視訊交友,視訊聊天,言情小說,愛情小說,AV片,A漫,AVDVD,情色論壇,視訊美女,AV成人網,成人交友,成人電影,成人貼圖,成人小說,成人文章,成人圖片區,成人遊戲,愛情公寓,情色貼圖,色情小說,情色小說,成人論壇


情色文學,色情小說,情色小說,色情,寄情築園小遊戲,情色電影,aio,av女優,AV,免費A片,日本a片,美女視訊,辣妹視訊,聊天室,美女交友,成人光碟

A片,A片,A片下載,做愛,成人電影,.18成人,日本A片,情色小說,情色電影,成人影城,自拍,情色論壇,成人論壇,情色貼圖,情色,免費A片,成人,成人網站,成人圖片,AV女優,成人光碟,色情,色情影片,免費A片下載,SEX,AV,色情網站,本土自拍,性愛,成人影片,情色文學,成人文章,成人圖片區,成人貼圖

Anonymous said...

A片,A片,情色,情色,A片,A片,情色,情色,A片,A片,A片下載,做愛,成人電影,.18成人,日本A片,情色小說,情色電影,成人影城,自拍,情色論壇,成人論壇,情色貼圖,情色,免費A片,成人,成人網站,成人圖片,AV女優,成人光碟,色情,色情影片,免費A片下載,SEX,AV,色情網站,本土自拍,性愛,成人影片,情色文學,成人文章,成人圖片區,成人貼圖

美女交友,AIO交友愛情館,AIO,成人交友,視訊交友網,視訊交友,拓網交友,PC交友,視訊交友90739,交友,情色交友,聊天室交友,辣妹視訊,視訊辣妹,美女視訊,視訊美女,情色視訊,日本AV,免費視訊聊天,視訊聊天,AV女優,AV,視訊聊天室,視訊,免費視訊,情人視訊網,本土自拍,自拍,AVDVD,SEX,微風成人,微風論壇,微風成人區,成人網站,成人,成人電影,嘟嘟成人網,成人貼圖,成人影片,成人圖片區,成人圖片,18成人,成人小說,成人影城,成人文章,成人論壇,愛情公寓,情色論壇,情色,色情聊天室,色情,情色貼圖,情色文學,色情小說,情色小說,寄情築園小遊戲,色情遊戲,情色電影,情色網,做愛,UT聊天室,聊天室,聊天,哈拉聊天室,豆豆聊天室,尋夢園聊天室,聊天室尋夢園,080苗栗人聊天室,苗栗人聊天室,080中部人聊天室,080聊天室,中部人聊天室,柔情聊天網,6K聊天室,小高聊天室,上班族聊天室,免費A片,A片,成人聊天室,一夜情聊天室,情色聊天室,色色網,免費AV

Anonymous said...

If I were gold für wow a boy again,world of warcraft gold I would practice perseverance wow gold cheap more often,maple meso and never give up a thing because it was or inconvenient. If we want light,Maple Story Account we must conquer darkness. Perseverance can sometimes equal genius in its results.wow gold kaufen “There are only two creatures,”cheap maplestory mesos syas a proverb, “who can surmount the pyramids—the eagle and the snail.” If I were a boy again,wow geld I would school myself into a habit of attention;maple mesos I would let nothing come between me and the subject in hand.maple story power leveling I would remember that a good skater never tries to skate in two directions at once.billig wow gold The habit of attention becomes part of our life, if we begain early enough. I often hear grown up people say maple story items“ I could not fix my attention on the sermon or book, although I wished to do so” , wow powerlevelingand the reason is, the habit was not formed in youth. If I were to live my life over again,wow leveling I would pay more attention to the cultivation of the memory. I would strengthen that faculty by every possible means,wow power leveling and on every possible occasion.maplestory powerleveling It takes a little hard work at first

eda said...

情趣按摩棒,自慰套,角色扮演,按摩棒,跳蛋,跳蛋,
.,.,

情趣,性感丁字褲,情趣,角色扮演服,吊帶襪,丁字褲,情趣用品,跳蛋,男女,
潤滑液,SM,內衣,性感內衣,自慰器,充氣娃娃,AV,
按摩棒,電動按摩棒,飛機杯,視訊,自慰套,自慰套,情趣用品,情趣內衣,