Performance of XML/XSL is tricky. For example, if your page is quasi-static, i.e.
it only changes every 10 minutes, then some servlet engines can cache the results
and serve them as fast as static pages. Then, the XSL overhead is meaningless.
Also, the XSL performance depends greatly on the complexity of your stylesheet and
your JSP-generated XML page.
There are two XSL techniques with very different performance. The first, as you
mentioned, filters the output of a servlet with XSL. The second uses XML and XSL
to create a JSP file. The second method is much faster because each request only
incurs JSP overhead not the XSL overhead.
As Mike mentioned, the value of XSL really depends on your application. If you
have lots of JSP pages with lots of random formatting tags, XSL can save your
life. With XSL, you can just change the stylesheet and all the formatting changs
without mucking with the JSP pages. But if you have only 3-5 JSP pages formatting
regular data like database queries, then XSL is probably overkill.
Here are some performance numbers using Resin 1.1.b3. The same page was used in
each case, just using different techniques. The page size is around 6k.
492 OPS, 2.03ms -- static file
383 OPS, 2.53ms -- some trivial JSP
337 OPS, 2.96ms -- XTP: using XSL to generate JSP
40 OPS, 24.98ms -- XSL filters the JSP output
In this test case, the XSL overhead is 23ms over the 2ms required to serve a
static file. For comparison, a simple database query (about 10 rows using MySql)
for this configuration has an overhead of about 5ms. Of course, if you're using a
slow servlet engine or a slow database driver, then the XSL overhead will be a
much smaller percentage of your total page performance.
The test page is part of the Resin JSP tutorial (add_page.xtp. If you download
Resin 1.1.b3 and go to the tutorial you can see what the page is doing.) The JSP
is trivial; it just uses getRealPath to tell exactly where the user should put the
new file. The XSL is a little more complex. It does the page layout and also
creates the navigation based on a toc.xml file. So the complexity of the page is
a little more than the Caucho home page and adds a little JSP.
Scott Ferguson
Caucho Technology
Brien Voorhees wrote:
> I've heard a lot of great things about using XML in combination with JSP to
> make it easier to change the presentation for other languages(Spanish,
> German, etc.) and protocols (e.g. WAP/WML). I know very little about XML
> but from what I have read it seems like it would have very significant
> run-time overhead. Is this true? A lot of people seem to be using it (or
> recommending it) so maybe it's not as bad as I think.... Or maybe the
> assumption is that if you have a web-server farm it doesn't really matter if
> the load-capacity of each server is diminished by the xml-translation
> overhead (as long as it doesn't put more load on the back-end resources,
> which it probably wouldn't) since it's cheap and easy to toss a few more
> front-end (web/servlet/jsp/EJB-client) servers in the farm.
>
> I'm in the early stages of developing a very large, (hopefully) highly
> scalable web site and I'm trying to decide if it's worth it to go down the
> XML path or if it's just going to be another heavyweight API that'll take
> time to learn and lots of cpu time to run (as if servlets, JSP, EJB, HTML,
> JavaScript, OODB, etc weren't enough).
>
> Any comments/recommendations would be appreciated.
>
> I've included at the bottom of this message a snippet from
> www.OrionServer.com which mentions using XML to handle HTML and WML.
>
> Brien Voorhees
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
