Re: XML/XSL on the client for dynamic UI

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