Subject: Re: XML/XSL on the client for dynamic UI From: Stefano Mazzocchi <stefano@xxxxxxxxxx> Date: Tue, 02 Nov 1999 13:25:27 +0100 |
Tim Taylor wrote: > > Mark Hayes wrote: > > > > > From: Tim Taylor [mailto:ttaylor@xxxxxxxxxx] > > > Is every page dynamic with every request? I've found that > > > with Cocoon, > > > once a page is cached, it frequently finishes processing in > > > under 50ms. > > > > Just curious: By "cached" do you mean that only the stylesheet and source > > document are cached with Cocoon, or is the result document cached as well? > > I assume the result is not cached, but I just wanted to be sure. 50 ms is a > > good number. > > Actually, I assumed the result was cached. Also, remember that 50ms was > the ceiling once cached. Here are some numbers: > > first request, no cache: 2934 ms > reload, cached: 5 ms > reload, XML "touched", XSL cached (presumably): 2366 ms > reload, cached: 4 ms > reload, XML cached (presumably), XSL "touched": 2672 ms > reload, cached: 5 ms > > This is with Cocoon configured to use OpenXML and XSL:P, though, for the > simple XML and stylesheet I used there probably wouldn't be much > difference with other parsers and processors. I think it would be. Try the XML4j/LotusXSL couple. > Anyhow, the point isn't > to be a benchmark (too many variables), but just to point out that > caching can give you order of magnitude improvements. Of course, I > should also point out that Cocoon is a memory hog...no suprises there :) It is. Cocoon is based on DOM and this requires all the stuff to go directly into memory. We all agree that DOM is the wrong approach for XML server side processing (like both James Clark and Mike Key have shown in their software) and event-based incremental operation is the way to go. In fact, after the release of Cocoon 1.5, we are currently designing Cocoon2 which will be event-based and _much_ less memory consuming. The final goal is to be able to generate a 100 Mb database report using a few Mb JVM heap size. This also goes along with other efforts such as stylesheet compilation that is being implemented in XSL:P, the new incremental formatting API James Tauber and Mike Key are proposing for Fop and server side XML compiled pages for SAX-direct XML generation that removes parsing overhead. Please, checkout the details on the web site. Lot's of stuff to do, it's true, and will take some time, but we are fully aware of the issues with todays implementations and Cocoon componentized architecture allows other projects to evelolve independently, thus increasing the development speed. > I've attached my test documents. Please disregard the content, I put it > together when I was just learning XML :) > > FYI, the developers have some pretty agressive goals with respect to > non-cached processing times. Yes. It is _clear_ that 3000ms for a server page generation is _NOT_ acceptable for a real use of the technology. > The project is worth checking out at http://java.apache.org/ Thanks. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <stefano@xxxxxxxxxx> Friedrich Nietzsche XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XML/XSL on the client for dynam, Tim Taylor | Thread | Re: XML/XSL on the client for dynam, James Clark |
Re: How can you tell if a variable , David Carlisle | Date | Re: MIF output from XT, Oliver Becker |
Month |