You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by anish sheth <an...@hotmail.com> on 2000/04/05 22:15:16 UTC

cocoon performance

I am trying to push cocoon in our company.  That's why I am
collecting all the "ammunition".
Are there any performance issues with xsl and xml processing using cocoon.  
We are planning to use the product for handling different style for 
different clients and generate the content using xml.

Compared to jsp, how will be cocoon's performance.  Our main
drive is to support multiple customers using more or less the same content.


Thanks,


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Re: cocoon performance

Posted by Stefano Mazzocchi <st...@apache.org>.
Edwin Glaser wrote:
> 
> Hello,
> 
> Stefano Mazzocchi wrote:
> 
> >> Will it be possible, with Cocoon 2, to begin to send data to the client before
> >> "processing" (XSP, XSLT, XSL ...) is finished ? (with SAX, if I've understood)
> 
> >in theory, yes.
> 
> > in practice, you need an incremental XSLT and none are available, but
> > this is not something I can control :(
> 
> Hmmm, it can be done with an ordinary XSLT processor.

I can't see how.

> But porting will be hard until we get a standard for extention elements.

This will happen soon, for what I've heard from the people inside the
XSLT WG.
 
> If you put a producer into an extention element or an extention function,
> that returns a node-set, you can do it in one pass. If this node-set
> uses a lazy-evaluation strategy, you will be able to render the output,
> while the producer is still working. Arkin suggested to implement such
> a thing on top of the castor package.

Careful. You are talking about a producer... we are talking about XSLT
processors. Big difference.
 
> Your stylesheet may include templates like this one:
> 
> <xsl:include "render-content.xsl"/>
> 
> <xsl:template match="content[@id]">
> 
>   <xsl:variable name="content">
>     <cocoon:generator type="sql" connection="foo_connection">
>       select * from foo_table where id = <xsl:value-of select="@id"/>
>     </cocoon:generator>
>   </xsl:variable>
> 
>  <xsl:apply-templates select="$content" mode="render-content"/>
> 
> <xsl:template>
> 
> At first, this template looks strange. 

well, it is very close to pattern that XSP use with taglibs. (some say
it's the exact same thing and should be combined)

> But as soon as you get used to it,
> the combination of extention elements with the apply-templates builtin
> becomes a very powerful design pattern. 

Totally, the only problem is that unless used very carefully, XSLT
extentions tend to be interpreted at run-time... instead of being
compiled inside the page as a generator.

> I have no idea how to merge this
> kind of producers with the sitemap approach. 

you mean xslt extentions? I see no difference from a normal stylesheet.

> But I think as soon as we
> find a solution, we will get the next generation of XML tools but one.

Still I don't understand how you can do just-in-time xslt
transformations without writing a carefully designed processor for doing
that. But I'm probably missing your point.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Re: cocoon performance

Posted by Edwin Glaser <ed...@pannenleiter.de>.
Hello,

Stefano Mazzocchi wrote:

>> Will it be possible, with Cocoon 2, to begin to send data to the client before
>> "processing" (XSP, XSLT, XSL ...) is finished ? (with SAX, if I've understood)

>in theory, yes.

> in practice, you need an incremental XSLT and none are available, but
> this is not something I can control :(

Hmmm, it can be done with an ordinary XSLT processor. But porting will
be hard until we get a standard for extention elements.

If you put a producer into an extention element or an extention function,
that returns a node-set, you can do it in one pass. If this node-set
uses a lazy-evaluation strategy, you will be able to render the output,
while the producer is still working. Arkin suggested to implement such 
a thing on top of the castor package.

Your stylesheet may include templates like this one:


<xsl:include "render-content.xsl"/>

<xsl:template match="content[@id]">

  <xsl:variable name="content">
    <cocoon:generator type="sql" connection="foo_connection">
      select * from foo_table where id = <xsl:value-of select="@id"/>
    </cocoon:generator>
  </xsl:variable>

 <xsl:apply-templates select="$content" mode="render-content"/>

<xsl:template>


At first, this template looks strange. But as soon as you get used to it,
the combination of extention elements with the apply-templates builtin
becomes a very powerful design pattern. I have no idea how to merge this
kind of producers with the sitemap approach. But I think as soon as we
find a solution, we will get the next generation of XML tools but one.

-- 
Edwin Glaser -- edwin@pannenleiter.de


Re: cocoon performance

Posted by Stefano Mazzocchi <st...@apache.org>.
Eric SCHAEFFER wrote:

> Will it be possible, with Cocoon 2, to begin to send data to the client before
> "processing" (XSP, XSLT, XSL ...) is finished ? (with SAX, if I've understood)

in theory, yes.

in practice, you need an incremental XSLT and none are available, but
this is not something I can control :(

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Re: cocoon performance

Posted by Eric SCHAEFFER <es...@posterconseil.com>.
----- Original Message -----
From: Stefano Mazzocchi <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Thursday, April 06, 2000 7:23 PM
Subject: Re: cocoon performance


> Ulrich Mayring wrote:
> >
> > Roman Kunert wrote:
> > >
> > > Fetching a Table with about 15.000 rows (each row 2 columns
> > > varchar(255)) using SQLProcessor and converting it to PDF and sending it
> > > to another client took about 3 minutes.
> >
> > Pretty impressive for a measly Pentium (sorry ;-)
> >
> > > For this task the webserver rendered 504 pages and needed about 100Mb
> > > heap space.
> > >
> > > As the generator should be capable of rendering up to 100.000 rows I am
> > > really looking forward to Cocoon2, or is there another way to achieve
> > > performance (via xsp, caching, etc. )?
> >
> > Just a stupid question: why don't you render, say, 100 rows at first and
> > then, while the user reads them, fetch some more in the background?
>
> Because you can't with Cocoon1... that's the problem :)

Will it be possible, with Cocoon 2, to begin to send data to the client before
"processing" (XSP, XSLT, XSL ...) is finished ? (with SAX, if I've understood)

Eric.

>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <st...@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>


Re: cocoon performance

Posted by Stefano Mazzocchi <st...@apache.org>.
Ulrich Mayring wrote:
> 
> Roman Kunert wrote:
> >
> > Fetching a Table with about 15.000 rows (each row 2 columns
> > varchar(255)) using SQLProcessor and converting it to PDF and sending it
> > to another client took about 3 minutes.
> 
> Pretty impressive for a measly Pentium (sorry ;-)
> 
> > For this task the webserver rendered 504 pages and needed about 100Mb
> > heap space.
> >
> > As the generator should be capable of rendering up to 100.000 rows I am
> > really looking forward to Cocoon2, or is there another way to achieve
> > performance (via xsp, caching, etc. )?
> 
> Just a stupid question: why don't you render, say, 100 rows at first and
> then, while the user reads them, fetch some more in the background?

Because you can't with Cocoon1... that's the problem :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Re: cocoon performance

Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> 
> Just an asside, I have found that between Cocoon and Allaire Cold Fusion, on
> similar hardware, the performance difference is negligable (the difference in
> time varies on the server load--sometimes Cocoon is faster, sometimes Cold
> Fusion).  When you add in the fact that the transforms that Cocoon does are
> more
> complex--and the formatting more flexible, Cocoon is the hands down winner.

Holy cow, hear that! I thought Cocoon was the slowest piece of code
ever!
 
> In the interest of fairness:
> The templates that we must work with are very complex in Cold Fusion, but
> relatively simple for Cocoon.  I believe that the big difference between the
> two
> is that the JVM interpretation (or JITC) is much quicker than Cold Fusion
> script.
> The parts of the site that take the longest are the database access times.  I
> have
> found that sometimes a carefully crafted SQL statement can take much longer
> than several smaller SQL statements.
> 
> The major problem with SQL in general, is that it is the limiting factor for
> most
> performance tests.

Ok, I see... unfair comparison.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Re: cocoon performance

Posted by Berin Loritsch <bl...@infoplanning.com>.
Just an asside, I have found that between Cocoon and Allaire Cold Fusion, on
similar hardware, the performance difference is negligable (the difference in
time varies on the server load--sometimes Cocoon is faster, sometimes Cold
Fusion).  When you add in the fact that the transforms that Cocoon does are
more
complex--and the formatting more flexible, Cocoon is the hands down winner.

In the interest of fairness:
The templates that we must work with are very complex in Cold Fusion, but
relatively simple for Cocoon.  I believe that the big difference between the
two
is that the JVM interpretation (or JITC) is much quicker than Cold Fusion
script.
The parts of the site that take the longest are the database access times.  I
have
found that sometimes a carefully crafted SQL statement can take much longer
than several smaller SQL statements.

The major problem with SQL in general, is that it is the limiting factor for
most
performance tests.

Ulrich Mayring wrote:

> Roman Kunert wrote:
> >
> > Fetching a Table with about 15.000 rows (each row 2 columns
> > varchar(255)) using SQLProcessor and converting it to PDF and sending it
> > to another client took about 3 minutes.
>
> Pretty impressive for a measly Pentium (sorry ;-)
>
> > For this task the webserver rendered 504 pages and needed about 100Mb
> > heap space.
> >
> > As the generator should be capable of rendering up to 100.000 rows I am
> > really looking forward to Cocoon2, or is there another way to achieve
> > performance (via xsp, caching, etc. )?
>
> Just a stupid question: why don't you render, say, 100 rows at first and
> then, while the user reads them, fetch some more in the background?
>
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org


Re: cocoon performance

Posted by Ulrich Mayring <ul...@denic.de>.
Roman Kunert wrote:
> 
> Fetching a Table with about 15.000 rows (each row 2 columns
> varchar(255)) using SQLProcessor and converting it to PDF and sending it
> to another client took about 3 minutes.

Pretty impressive for a measly Pentium (sorry ;-)

> For this task the webserver rendered 504 pages and needed about 100Mb
> heap space.
> 
> As the generator should be capable of rendering up to 100.000 rows I am
> really looking forward to Cocoon2, or is there another way to achieve
> performance (via xsp, caching, etc. )?

Just a stupid question: why don't you render, say, 100 rows at first and
then, while the user reads them, fetch some more in the background?

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: cocoon performance

Posted by Roman Kunert <ro...@hsh-berlin.com>.
We plan to build up a DB -> PDF/HTML generator and I evaluate the
chances for using Cocoon for this task:

Today I got the following results:

Database-Server: Pentium 266, 196Mb RAM, Linux 6.0, Oracle 8.0.1

Webserver: Pentium III, 700Mhz, 128Mb RAM, Linux 6.3, Apache 1.3.9,
JServ 1.1, Cocoon 1.7.2, JDK 1.1.7

Network: 100Mbit

Fetching a Table with about 15.000 rows (each row 2 columns
varchar(255)) using SQLProcessor and converting it to PDF and sending it
to another client took about 3 minutes.

For this task the webserver rendered 504 pages and needed about 100Mb
heap space. 

As the generator should be capable of rendering up to 100.000 rows I am
really looking forward to Cocoon2, or is there another way to achieve
performance (via xsp, caching, etc. )?

Ro.

help writing a processor

Posted by Robert Curlee <rc...@ucsd.edu>.
Can someone point me in the right direction on how to write a processor
for cocoon?  I have no experience with DOM programming and I'm new to
XML.  Looking at the processor java code is making my head spin.  It has
no comments and it's difficult to figure out what's going on.  Can
anyone recommend good books or on line documentation which would help me
in writing a processor?

Thank you.

--
Robert Curlee                           CAIDA, 0505
Vis/Sim Programmer                      SD Supercomputer Center
phone: (858) 822-3605                   9500 Gilman Drive
http://www.caida.org                    La Jolla, CA 92093

Re: cocoon performance

Posted by Thorbjoern Ravn Andersen <ra...@mip.sdu.dk>.
On Thu, 6 Apr 2000, Stefano Mazzocchi wrote:

> Then wait for Cocoon2... where you'll see that problem much reduced and,

Do you have an approximate day we can reserve for this? :-)

-- 
  Thorbjørn Ravn Andersen               "...plus...Tubular Bells!"
  http://www.mip.sdu.dk/~ravn


Re: cocoon performance

Posted by Stefano Mazzocchi <st...@apache.org>.
remo strotkamp wrote:
> 
> anish sheth wrote:
> >
> > I am trying to push cocoon in our company.  That's why I am
> > collecting all the "ammunition".
> > Are there any performance issues with xsl and xml processing using cocoon.
> 
> not really performance but 'scalability':
> 
> Once tried to transform a 20MB xml file with a not too complicated
> xsl file into html, and the JVM run constantly out of memory even
> when I incresed its maximum size to sth like 150MB.....
> 
> But then again, if you have 20MB xml files you have probably done some
> things wrong during the design anyway....
> 
> I did it just for 'fun', so wasn't really an issue..
> 
> But still, even a 4MB xml file might take a minute or so to get
> transformed....
> 
> doesn't really help I guess, and is for sure no ammo..
> 
> but all the same cocoon rules :-)

Then wait for Cocoon2... where you'll see that problem much reduced and,
hopefully, totally eliminated once we have an incremental XSLT processor
(if ever!)... anyway cocoon2 big selling point will be it's _much_
reduced memory footpring, even under heavy load...

plus _lost_ of other things like the sitemap you'll get instantaneously
addicted with :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Re: cocoon performance

Posted by remo strotkamp <re...@ccrl.nj.nec.com>.
anish sheth wrote:
> 
> I am trying to push cocoon in our company.  That's why I am
> collecting all the "ammunition".
> Are there any performance issues with xsl and xml processing using cocoon.

not really performance but 'scalability':

Once tried to transform a 20MB xml file with a not too complicated
xsl file into html, and the JVM run constantly out of memory even 
when I incresed its maximum size to sth like 150MB.....

But then again, if you have 20MB xml files you have probably done some
things wrong during the design anyway....

I did it just for 'fun', so wasn't really an issue..

But still, even a 4MB xml file might take a minute or so to get
transformed....




doesn't really help I guess, and is for sure no ammo..

but all the same cocoon rules :-)


remo