[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: (SUMMARY) performant templating language for XML


xsl hardware
Hi All.

First off, thanks to everyone who contributed to this thread.  I'm going  
to sum up the responses I got.

To recap very briefly:  We have a large store of unique XML documents and  
a CMS capable of generating meta data about those docs in XML format.  I  
outlined a performance scenario with 10 requests/sec with one 80k and 2  
<10k transforms for each request.

The solutions:

*** optimize XSL and the environment and it could probably work out just  
fine
The most common response (and one that was given with impressive backing  
information) was that XSL should be able to handle the loads I outlined.   
There are many optimization to the architecture that can improve  
performance for any transform, and many more than can be applied to  
specific transforms to improve them one by one.

*** caching
Several people suggested caching.  Because the 10 users/second are spread  
among 100,000 unique documents, and the user's viewing permissions are a  
big part of the dynamic aspect of a given page, caching can be hard to  
architect in.  My understanding is that caching is best used for pieces of  
content are shared among many page views and that do not vary from one  
view to the next.  Most of our content violates either one or the other of  
these criteria.

*** pre-render/code generation
Our own best solution and that seconded by several others was to have XSL  
transforms done in the CMS and the web application show the results of  
those transforms.  A twist could be that XSL output is sprinkled with  
generated code that gets executed at runtime in a lightweight web  
templating language.  To be fair, this IS a form of caching, so listing it  
as a separate bullet point isn't quite fair.

*** use XQuery instead
Two respondents suggested XQuery as a better performing alternative to  
XSL.  I'm following up to see how well suited XQuery seems to be for  
templating.  I'd also need to confirm the assertion that XQuery is fast  
across the board than XSLT.  (NOT to start another comparison thread!!!!!)

*** use cocoon
I've also always wanted to use Zope someday.  I think we're committed to  
Servlets in this project though.

*** hardware
Someone responded offline with information about XML/XSL hardware  
acceleration devices.  This is a fascinating development as far as I'm  
concerned, but I'm pretty darn gun shy about moving pieces of our  
architecture into dedicated hardware.  My take is that the past ten years  
have brought a lot of progress in standardizing and comodotizing server  
infrastructure to good effect.  I worry that dedicated XML hardware flies  
in the face of that progress.  At the same time I have no doubt for the  
implementation that truly demand it it is a lifesaver.


Thanks again to all who responded!


------------>Nathan








On Wed, 29 Dec 2004 18:43:38 -0500, David Megginson  
<david.megginson@g...> wrote:

> On Wed, 29 Dec 2004 11:58:16 -1000, Joe Dane <joe.dane@g...> wrote:
>
>> however, I've got to say that your requirements don't seem to be so
>> strict that you should be ruling out XSLT, even if you have to run the
>> transform online.
>
> The choice between JSP and XSLT comes down to whether the pages are
> just dynamic, or dynamic and customized.
>
> If they are dynamic *and* customized, and you're in a J2EE environment
> anyway, you probably want to use JSP rather than XSLT -- JSPs compile
> to Java code, so they can change content without requiring a reparse;
> XSLT usually compiles to static HTML, so any change in content
> requires a reparse.  If you're simply publishing news stories or
> chapters of a technical manual, where every user sees the same thing
> for (say) an hour before the content changes, then XSLT and a good
> cache will be a great solution; if you're showing user account
> information, shopping carts, the current weather in Tulsa, or anything
> else that is the result of a real-time database query, then JSP
> templates will give an significant performance advantage, since the
> HTML from the XSLT will not usually be cacheable.
>
> It's also an order of magnitude or so easier to find and hire people
> with JSP skills than with XSLT skills, in case your company is worried
> about your quitting or walking in front of a bus a year from now.  On
> the other hand, as I mentioned before, XSLT is more portable if you
> decide to change from a Java-based server to something else later on.
>
>
> All the best,
>
>
> David
>



-- 


.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.