[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: (SUMMARY) performant templating language for XML
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|