Discussions

Performance and scalability: XSLT DOM vs JDBC

  1. XSLT DOM vs JDBC (7 messages)

    Does someone have performance data comparing data retrieval using JDBC and Constructing a DOM Tree from the resultset.

    I know that the JDBC is a much faster operation, but then, I would greatly appreciate if someone could throw some light on this.

    I have to retrieve about 8000 rows from the database and then display the same using XSLT. I am of the opinion that it makes more sense to use JSTL rather than using XSLT.

    There are people who believe otherwise. They think that the JDBC part would be more of a bottle neck than the XSLT part


    Thanks,


    Venu

    Threaded Messages (7)

  2. XSLT DOM vs JDBC[ Go to top ]

    Does someone have performance data comparing data retrieval using JDBC and Constructing a DOM Tree from the resultset.I know that the JDBC is a much faster operation, but then, I would greatly appreciate if someone could throw some light on this.I have to retrieve about 8000 rows from the database and then display the same using XSLT. I am of the opinion that it makes more sense to use JSTL rather than using XSLT.There are people who believe otherwise. They think that the JDBC part would be more of a bottle neck than the XSLT partThanks,Venu

    The fastest solution is this:

    1) Retrieve the information using JDBC and put the 8000 rows in a Vector, ArrayList, whatever.

    2) With the information in the Vector, build on the fly a StringBuffer containing the XML representation of this information.

    3) Send the XML document to the browser with a tag such as: <xsl:include template.xsl> (being 'template.xsl' the name of the template that generates the HTML code.)

    4) Let the browser perform the heavy process of mixing XML with XSL.

    Depending of your situation, you may unify step 1 and 2, because - of course - the fastest solution is to build the StringBuffer with the XML document on the fly, while you traverse the ResultSet.

    Two advices:

    . Never use DOM: it generates a lot of small object that need to be garbage collected.
    . Never perform XSLT operations in the application server: always delegate on the browser.



    Jose Ramon Huerga
    http://www.terra.es/personal/jrhuerga
  3. XSLT DOM vs JDBC[ Go to top ]

    Use a Value List Handler to control the search, cache the results, and provide the results to the client in a result set whose size and traversal meets the client's requirements
    hope this helps
  4. Thanks[ Go to top ]

    Thank you guys.

    Looks as if building the DOM tree out of a ResultSet is a faster process than getting 8000 rows out of the DB. (Well depends on the database with MSSQL 2000 the contrary is true).

    MY approach right now is that I am building a DOM tree and then converting it to a String and sending it to the browser. The browser takes this string, loads it into a DOM tree and then uses XSL to display the results as desired.

    The time taken on the server side for getting the data out of the DB and then building the DOM Tree and then getting a string representation is about 3.5 to 4 sec.

    It is however taking the browser a little over a min. to display it and then process is memory intensive. IE sucks out all the CPU for about a min. to get this transformation job done.

    If the client was a swing based applet, it would have taken about 5 to 6 secs. to do the complete job. XML is a good for many reasons but then it is a killer as far as performance is concern. Can not do much can we. It is HOT!!!
  5. Thanks[ Go to top ]

    Looks as if building the DOM tree out of a ResultSet is a faster process than getting 8000 rows out of the DB. (Well depends on the database with MSSQL 2000 the contrary is true).MY approach right now is that I am building a DOM tree and then converting it to a String and sending it to the browser ... The time taken on the server side for getting the data out of the DB and then building the DOM Tree and then getting a string representation is about 3.5 to 4 sec.

    Venu, excuse me, but this doesn't make any sense at all. The only reason you should create a DOM tree is to edit the XML data, modify it, and send the data to the browser. If you are going to merely generate a XML document from rows of a database (and you are not going to alter the data) it is completely useless to build a DOM tree. If the generation lasts as much as 4 seconds, then... what happens in that 4 seconds when other users try to get job done? Do they need to wait 4 seconds until the application server is ready to process more request ?

    Of course, if you are building such a huge DOM tree, then the 'garbage collector' is going to waste a lot of CPU resources performing 'full garbage collection'. It doesn't make any sense.

    My propose is:
      
      1. get ResultSet
      2. while there is data
         2.1. read a new row
           2.1.1. read a field
           2.1.2. StringBuffer.add (<tag> + field + </tab>)
           2.1.3. read a field
           2.1.4. StringBuffer.add (<tag> + field + </tab>)
      3. send the data to the browser.

    This approach reuses the same object - StringBuffer - and is very fast (never, the creation - an destruction - of a DOM object is going to be faster: NEVER).

    ... The browser takes this string, loads it into a DOM tree and then uses XSL to display the results as desired ... It is however taking the browser a little over a min. to display it and then process is memory intensive. IE sucks out all the CPU for about a min. to get this transformation job done.

    Well, XSL is very expensive. On the other hand, maybe if you look at the XPATH statements, maybe you can find some special XPATH that can be improved.

    Also, you can try to use faster and newer version of MSXML.DLL. This library can be freely downloaded from Microsoft web site.


    Jose Ramon Huerga
    http://www.terra.es/personal/jrhuerga
  6. Thanks[ Go to top ]

    well If your application does a large amount of XML parsing, it is important to look at the parsing method being used to do it. Two of the basic parsing options are the Document Object Model (DOM) which you saying and the other is Simple API for XML (SAX). DOM parsers require much more overhead because they parse an entire XML document at once and create an in memory object representation of the XML tree. This is helpful if the program requires either significant manipulation or the creation of XML documents. However, if your application simply needs to parse through a document once and deal with the data
    right away, the SAX parser is much more efficient. It reads through a document once and invokes hook methods to process each tag that it comes across in the document.

    my sugessiton is - do the SAX
  7. Thanks[ Go to top ]

    well If your application does a large amount of XML parsing, it is important to look at the parsing method being used to do it. Two of the basic parsing options are the Document Object Model (DOM) which you saying and the other is Simple API for XML (SAX). DOM parsers require much more overhead because they parse an entire XML document at once and create an in memory object representation of the XML tree. This is helpful if the program requires either significant manipulation or the creation of XML documents. However, if your application simply needs to parse through a document once and deal with the dataright away, the SAX parser is much more efficient. It reads through a document once and invokes hook methods to process each tag that it comes across in the document. my sugessiton is - do the SAX

    Remember: he is not parsing XML. He is generating XML. ON the other hand, I agree with you: DOM is very expensive, and it is only helpful when you need to modify the XML, which is not the case.


    Jose Ramon Huerga
    http://www.terra.es/personal/jrhuerga
  8. XSLT DOM vs JDBC[ Go to top ]

    Thanks Jose, for the Good advice! I had in fact changed to your approach, exactly for the same reason you have mentioned now, after reading your first response.

    Creating DOM for 8000 rows * n number of users on the server side is going to take quite a bit of resources and slow down my application.


    Thanks,


    Venu