You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nicola Ken Barozzi <ba...@nicolaken.com> on 2002/01/28 19:40:03 UTC

Cocoon for docs generation

Cocoon in docs build is slow. :-(
On the same documentation set
(PIII 1Ghz, 512 Mb, W$2000SP1, Jdk Sun 1.3.1_01):

Anakia: 4 sec
Cocoon of two weeks ago: 50 sec
Cocoon of two weeks ago precompiled sitemap: 16 sec
Cocoon HEAD: 45 sec
Cocoon HEAD with cocoon.xconf tweaks: 38sec
Cocoon HEAD precompiled sitemap: 18 sec
Cocoon HEAD+TreeProcessor: 2 sec (only index.html compiled)

I'm struggling to keep other developers on the project use Cocoon, but it's
dead hard, and I can't blame them.
It seems that link crawling and setup times are the main culprit.
In what direction should I go to get faster performance?

Also, do you think that docs generation can be a good performance
measurement of Cocoon speed?
I would like to make the docs generation a Cocoon speed index: SpeCoon,
using my machine as a reference. ;-)
It would be nice if Gump ran the docs generation nightly (does it?) and
logged how much it took.
We could see daily how performance was better or worse.

Comments?

--
Nicola Ken Barozzi                 xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
          ...so don't cry baby, don't cry...
                                                  Paul Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Cocoon for docs generation

Posted by Bernhard Huber <be...@a1.net>.
Hi,

>>If you launch "build docs" the first file in build/cocoon/docs are 
>>generated, that's okay.
>>
>>If you launch "build docs" a second time all images, each html is 
>>generated once again, as far as i understand.
>>Note: I have not changed the documentation source files.
>>
>>That might be an explanation for the poor performance.
>>I think tuning cocoon.xconf only might not be the only solution.
>>
>>Sadly I have not found the key for the reason, checking too many sources...
>>Perhaps some cache, environment/commandline gurue might help?
>>
>
>Just a idea, why don't you use the FilesystemStore or the JispFilesystemStore
>(see scratchpad) for that. Then you would have the Files persistent!?
>
I have switched on all the caching stuff, but still the resources (html, 
jpeg, et al) are written
to the destination directory.
I checked the logs html files are not generated from but are taken from 
the cache. That's greate.
But the html content is still written to the destination directory, even 
if the html file exists already

That's what I wanted to point to.

bye bernhard



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: Cocoon for docs generation

Posted by Gerhard Froehlich <g-...@gmx.de>.
Hi,

>>Also, do you think that docs generation can be a good performance
>>measurement of Cocoon speed?
>>
>I have checked a bit what is done if you launch "build docs".
>
>If you launch "build docs" the first file in build/cocoon/docs are 
>generated, that's okay.
>
>If you launch "build docs" a second time all images, each html is 
>generated once again, as far as i understand.
>Note: I have not changed the documentation source files.
>
>That might be an explanation for the poor performance.
>I think tuning cocoon.xconf only might not be the only solution.
>
>Sadly I have not found the key for the reason, checking too many sources...
>Perhaps some cache, environment/commandline gurue might help?

Just a idea, why don't you use the FilesystemStore or the JispFilesystemStore
(see scratchpad) for that. Then you would have the Files persistent!?

  Gerhard
 
"Sex... the pleasure is momentry, the position ridiculous,
and the expense damnable.
(Lord Chesterfield)"


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Cocoon for docs generation

Posted by Bernhard Huber <be...@a1.net>.
hi,

>Also, do you think that docs generation can be a good performance
>measurement of Cocoon speed?
>
I have checked a bit what is done if you launch "build docs".

If you launch "build docs" the first file in build/cocoon/docs are 
generated, that's okay.

If you launch "build docs" a second time all images, each html is 
generated once again, as far as i understand.
Note: I have not changed the documentation source files.

That might be an explanation for the poor performance.
I think tuning cocoon.xconf only might not be the only solution.

Sadly I have not found the key for the reason, checking too many sources...
Perhaps some cache, environment/commandline gurue might help?



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Cocoon 2.0 Error reporting

Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
>Well obviously there is a pipeline for /portal/user/login. The error is of
>course that I commented out the serializer by mistake. I am not sure if the
>error is more explanatory under 2.0.1 - I haven't checked yet.

I've just checked and it does the same :-(

Thank you for pointing it out. I will look at it.
It seems though that the error is not caught by the sitemap and is rethrown
to Cocoon, which decides to handle it this way.

> And so I would be +1000 for
>somehow making these type of beginner mistakes easy to find.

Unfortunately we all suffered from this thing; some changes I already did,
more I will do now.

Anyway, thank you for the example. It's just what I needed. :-)

Ken

--
Nicola Ken Barozzi                 xml-cocoon@nicolaken.com
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Cocoon 2.0 Error reporting

Posted by Matthew Langham <ml...@s-und-n.de>.
Hi,

on the subject of error reporting - calling the following pipeline:

>>

		<map:match pattern="portal/user/login">
    			<map:generate src="portal/resources/login.xml"/>
			<map:transform src="portal/styles/buildlogin.xsl">
				<map:parameter name="use-request-parameters" value="true"/>
			</map:transform>
    			<map:transform type="sql">
      				<map:parameter name="use-connection" value="portal"/>
	 		</map:transform>
			<!--
			<map:transform src="portal/styles/buildfeeds.xsl"/>
    			<map:transform type="sql">
      				<map:parameter name="use-connection" value="portal"/>
	 		</map:transform>
    			<map:serialize type="xml"/>
			-->
  		</map:match>
<<


(Yes I know its wrong)

Results in a 404 being returned to the browser and the log says:

>>
org.apache.cocoon.ResourceNotFoundException: No pipeline matched request:
/portal/user/login
<<

Well obviously there is a pipeline for /portal/user/login. The error is of
course that I commented out the serializer by mistake. I am not sure if the
error is more explanatory under 2.0.1 - I haven't checked yet.

But this is more to emphasize the fact that these types of error messages
make life really hard "out in the field". And so I would be +1000 for
somehow making these type of beginner mistakes easy to find.

Carsten - you hear me? :-)

Matthew

--
Open Source Group               sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30  mlangham@s-und-n.de - http://www.s-und-n.de
=================================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: Cocoon for docs generation

Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:barozzi@nicolaken.com]
> 
> Cocoon doc build - building jakarta-poi docs from sourceforge
> On the same documentation set
>  (PIII 1Ghz, 512 Mb, W$2000SP1, Jdk Sun 1.3.1_01):
> 
>  Anakia: 4 sec
> Cocoon of 16/01/2002: 50 sec
> Cocoon of 16/01/2002 precompiled sitemap: 16 sec
> Cocoon of 28/01/2002: 45 sec
> Cocoon 28/01/2002 with cocoon.xconf tweaks: 38sec
> Cocoon 28/01/2002 precompiled sitemap: 18 sec
> Cocoon 28/01/2002+TreeProcessor: 2 sec (only index.html compiled)
> Cocoon 2.0.1: 36 sec
> Cocoon 2.0.1precompiled sitemap: 14 sec
> 
> Cocoon 01/02/2001 : 33sec
> Cocoon 01/02/2001 precompiled sitemap: 12 sec
> Cocoon 01/02/2001 with Xerces2: 32sec
> Cocoon 01/02/2001 precompiled sitemap with Xerces2: 12 sec

That's interesting. Startup time & processing time are going down!
Keep these numbers lowering! ;)

Vadim



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Cocoon for docs generation

Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
Cocoon doc build - building jakarta-poi docs from sourceforge
On the same documentation set
 (PIII 1Ghz, 512 Mb, W$2000SP1, Jdk Sun 1.3.1_01):
 
 Anakia: 4 sec
Cocoon of 16/01/2002: 50 sec
Cocoon of 16/01/2002 precompiled sitemap: 16 sec
Cocoon of 28/01/2002: 45 sec
Cocoon 28/01/2002 with cocoon.xconf tweaks: 38sec
Cocoon 28/01/2002 precompiled sitemap: 18 sec
Cocoon 28/01/2002+TreeProcessor: 2 sec (only index.html compiled)
Cocoon 2.0.1: 36 sec
Cocoon 2.0.1precompiled sitemap: 14 sec

Cocoon 01/02/2001 : 33sec
Cocoon 01/02/2001 precompiled sitemap: 12 sec
Cocoon 01/02/2001 with Xerces2: 32sec
Cocoon 01/02/2001 precompiled sitemap with Xerces2: 12 sec

-- 
Nicola Ken Barozzi                 xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
          ...so don't cry baby, don't cry...
                                                  Paul Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Cocoon for docs generation

Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
From: "Nicola Ken Barozzi" <ba...@nicolaken.com>

> Cocoon in docs build is slow. :-(
> On the same documentation set
> (PIII 1Ghz, 512 Mb, W$2000SP1, Jdk Sun 1.3.1_01):
> 
> Anakia: 4 sec
> Cocoon of two weeks ago: 50 sec
> Cocoon of two weeks ago precompiled sitemap: 16 sec
> Cocoon HEAD: 45 sec
> Cocoon HEAD with cocoon.xconf tweaks: 38sec
> Cocoon HEAD precompiled sitemap: 18 sec
> Cocoon HEAD+TreeProcessor: 2 sec (only index.html compiled)

Cocoon 2.0.1: 36 sec
Cocoon 2.0.1precompiled sitemap: 14 sec

--
Nicola Ken Barozzi                 xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
          ...so don't cry baby, don't cry...
                                                  Paul Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Cocoon for docs generation

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:

>----- Original Message -----
>From: "Sylvain Wallez" <sy...@anyware-tech.com>
>To: <co...@xml.apache.org>
>Sent: Monday, January 28, 2002 8:52 PM
>Subject: Re: Cocoon for docs generation
>
>>Nicola Ken Barozzi wrote:
>>
>>>Cocoon in docs build is slow. :-(
>>>On the same documentation set
>>>(PIII 1Ghz, 512 Mb, W$2000SP1, Jdk Sun 1.3.1_01):
>>>
>>>Anakia: 4 sec
>>>Cocoon of two weeks ago: 50 sec
>>>Cocoon of two weeks ago precompiled sitemap: 16 sec
>>>Cocoon HEAD: 45 sec
>>>Cocoon HEAD with cocoon.xconf tweaks: 38sec
>>>Cocoon HEAD precompiled sitemap: 18 sec
>>>Cocoon HEAD+TreeProcessor: 2 sec (only index.html compiled)
>>>
>>Could you elaborate on the last line : do you mean Cocoon with
>>TreeProcessor is the fastest, or that is fails after the first page ?
>>Depending on this, I will be happy or sad ;)
>>
>It processes correctly index.html and related resources but doesn't crawl
>other pages.
>I've checked if the "cocoon-view=links" workson the webapp version: yes it
>does. :-)
>
Mmmh. This seems related to the Constants.LINK_OBJECT that's in the 
object model in commandline environment but not in http environment. 
I'll check that.

>BTW, when I use you treeprocessor on the current sample sitemap I get this
>error:
>Type 'parentcm' is not defined for 'generate' at
>file:/C:/jakarta-tomcat/webapps/cocoon/sitemap.xmap:1181:46
>
>then I delete the relevant pipeline and get:
>Type 'xmldbcollection' is not defined for 'generate' at
>file:/C:/jakarta-tomcat/webapps/cocoon/sitemap.xmap:1192:54
>
>Then delete DB pipelines and *all* samples work :-)
>
>It seems this is a feature, but them we have something not correct in
>current sitemap.
>
Yes, this is a feature : if the components for parentcm and xmldb aren't 
included by the build, the corresponding pipeline is incorect since it 
uses undeclared generators.

While the compiled sitemap ignores this silently but barfs when the 
offending pipeline is executed, the TreeProcessor checks that all used 
components are correctly declared and fails at read time if some aren't.

So we need the build to handle not only some conditional component 
declarations in the sitemap, but also pipeline snippets. Thoughts ?

>>>I'm struggling to keep other developers on the project use Cocoon, but
>>>it's dead hard, and I can't blame them.
>>>
>>>It seems that link crawling and setup times are the main culprit.
>>>In what direction should I go to get faster performance?
>>>
>>For setup time, the main point is pool size : set all Poolable
>>components with a pool-min="1" in cocoon.xconf
>>
>>>I would like to make the docs generation a Cocoon speed index: SpeCoon,
>>>using my machine as a reference. ;-)
>>>
>>On this subject, I proposed today to build a JMeter (an Apache project
>>;) test suite that could be used to compare Cocoon versions. I don't
>>know JMeter, so I'm looking for volunteers...
>>
>I've used JMeter already to test Cocoon in the past, but I've still to
>finish the logging stuff and the error doco.
>I think that the first thing is making a clean webapp with only testing
>stuff, that never changes.
>
Sure.

>What do you think could be used to measure performance aspects of cocoon?
>
We could extract some representative examples from the current cocoon 
samples which involve Cocoon core components (xsp, xsl, aggregation), 
but do not rely on external components such as remote http content or 
databases which may bias the results.

Sylvain

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Cocoon for docs generation

Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
To: <co...@xml.apache.org>
Sent: Monday, January 28, 2002 8:52 PM
Subject: Re: Cocoon for docs generation


> Nicola Ken Barozzi wrote:
>
> >Cocoon in docs build is slow. :-(
> >On the same documentation set
> >(PIII 1Ghz, 512 Mb, W$2000SP1, Jdk Sun 1.3.1_01):
> >
> >Anakia: 4 sec
> >Cocoon of two weeks ago: 50 sec
> >Cocoon of two weeks ago precompiled sitemap: 16 sec
> >Cocoon HEAD: 45 sec
> >Cocoon HEAD with cocoon.xconf tweaks: 38sec
> >Cocoon HEAD precompiled sitemap: 18 sec
> >Cocoon HEAD+TreeProcessor: 2 sec (only index.html compiled)
> >
> Could you elaborate on the last line : do you mean Cocoon with
> TreeProcessor is the fastest, or that is fails after the first page ?
> Depending on this, I will be happy or sad ;)

It processes correctly index.html and related resources but doesn't crawl
other pages.
I've checked if the "cocoon-view=links" workson the webapp version: yes it
does. :-)

BTW, when I use you treeprocessor on the current sample sitemap I get this
error:
Type 'parentcm' is not defined for 'generate' at
file:/C:/jakarta-tomcat/webapps/cocoon/sitemap.xmap:1181:46

then I delete the relevant pipeline and get:
Type 'xmldbcollection' is not defined for 'generate' at
file:/C:/jakarta-tomcat/webapps/cocoon/sitemap.xmap:1192:54

Then delete DB pipelines and *all* samples work :-)

It seems this is a feature, but them we have something not correct in
current sitemap.

> >I'm struggling to keep other developers on the project use Cocoon, but
it's
> >dead hard, and I can't blame them.
> >It seems that link crawling and setup times are the main culprit.
> >In what direction should I go to get faster performance?
> >
> For setup time, the main point is pool size : set all Poolable
> components with a pool-min="1" in cocoon.xconf
>
> >I would like to make the docs generation a Cocoon speed index: SpeCoon,
> >using my machine as a reference. ;-)
> >
> On this subject, I proposed today to build a JMeter (an Apache project
> ;) test suite that could be used to compare Cocoon versions. I don't
> know JMeter, so I'm looking for volunteers...

I've used JMeter already to test Cocoon in the past, but I've still to
finish the logging stuff and the error doco.
I think that the first thing is making a clean webapp with only testing
stuff, that never changes.
What do you think could be used to measure performance aspects of cocoon?

--
Nicola Ken Barozzi                 xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
          ...so don't cry baby, don't cry...
                                                  Paul Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: Cocoon for docs generation

Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> 
> Nicola Ken Barozzi wrote:
> 
> >Also, do you think that docs generation can be a good performance
> >measurement of Cocoon speed?
> >
> No, because Cocoon has an important warm up time that pays on the long
> run, but is dramatic for one-time command line processing.

It could show both figures: setup time as well as processing time.
setup + processing = total time.

Vadim



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Cocoon for docs generation

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:

>Cocoon in docs build is slow. :-(
>On the same documentation set
>(PIII 1Ghz, 512 Mb, W$2000SP1, Jdk Sun 1.3.1_01):
>
>Anakia: 4 sec
>Cocoon of two weeks ago: 50 sec
>Cocoon of two weeks ago precompiled sitemap: 16 sec
>Cocoon HEAD: 45 sec
>Cocoon HEAD with cocoon.xconf tweaks: 38sec
>Cocoon HEAD precompiled sitemap: 18 sec
>Cocoon HEAD+TreeProcessor: 2 sec (only index.html compiled)
>
Could you elaborate on the last line : do you mean Cocoon with 
TreeProcessor is the fastest, or that is fails after the first page ? 
Depending on this, I will be happy or sad ;)

>I'm struggling to keep other developers on the project use Cocoon, but it's
>dead hard, and I can't blame them.
>It seems that link crawling and setup times are the main culprit.
>In what direction should I go to get faster performance?
>
For setup time, the main point is pool size : set all Poolable 
components with a pool-min="1" in cocoon.xconf

>Also, do you think that docs generation can be a good performance
>measurement of Cocoon speed?
>
No, because Cocoon has an important warm up time that pays on the long 
run, but is dramatic for one-time command line processing.

>I would like to make the docs generation a Cocoon speed index: SpeCoon,
>using my machine as a reference. ;-)
>
On this subject, I proposed today to build a JMeter (an Apache project 
;) test suite that could be used to compare Cocoon versions. I don't 
know JMeter, so I'm looking for volunteers...

>It would be nice if Gump ran the docs generation nightly (does it?) and
>logged how much it took.
>We could see daily how performance was better or worse.
>
>Comments?
>
See inline !

Sylvain

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: Cocoon for docs generation

Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:barozzi@nicolaken.com]
> 
> Cocoon in docs build is slow. :-(
> On the same documentation set
> (PIII 1Ghz, 512 Mb, W$2000SP1, Jdk Sun 1.3.1_01):
> 
> Anakia: 4 sec
> Cocoon of two weeks ago: 50 sec
> Cocoon of two weeks ago precompiled sitemap: 16 sec
> Cocoon HEAD: 45 sec
> Cocoon HEAD with cocoon.xconf tweaks: 38sec
> Cocoon HEAD precompiled sitemap: 18 sec
> Cocoon HEAD+TreeProcessor: 2 sec (only index.html compiled)
> 
> I'm struggling to keep other developers on the project use Cocoon, but
it's
> dead hard, and I can't blame them.
> It seems that link crawling and setup times are the main culprit.
> In what direction should I go to get faster performance?
> 
> Also, do you think that docs generation can be a good performance
> measurement of Cocoon speed?
> I would like to make the docs generation a Cocoon speed index:
SpeCoon,
> using my machine as a reference. ;-)
> It would be nice if Gump ran the docs generation nightly (does it?)
and
> logged how much it took.
> We could see daily how performance was better or worse.

Good idea. +1.

Vadim


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org