[
Lists Home |
Date Index |
Thread Index
]
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@gmail.com> wrote:
> On Wed, 29 Dec 2004 11:58:16 -1000, Joe Dane <joe.dane@gmail.com> 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
>
--
.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.
|
