Nicola Ken Barozzi wrote: >----- Original Message ----- >From: "Sylvain Wallez" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
