Well, I'm currently using both (started with cinclude, then just curious to
use xinclude, ending up with them both;-), but have not yet noticed a big
difference between them (nor any problems). The only thing to keep in mind,
as far as I know, is that cinclude is cocoon-specific. I do not know if
there are important differences that may affect your performance.
A cocoon-guru's opinion would be very usefull here!
Bye,
Jan
----- Original Message -----
From: "Katharina Weimer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 19, 2004 3:20 PM
Subject: Re: slow pipeline (svg, aggregation)
> I'm using content aggregation as well a lot and somehow I'm not that
> satisfied with the speed of results too.
> I just found the cinclude transformer and am thinking about replacing my
> current content aggregations with it.. (Just did some tests and was quite
> satisfied with it !)
>
> My question: what's better? Using Cocoons Implementation Cinclude, or is
it
> better to use the standardized XInclude to be not depended on Cocoon
itself?
> Are there big differences ?
>
> Greetz,
> Katharina
>
>
>
> > I also used an aggregation to create my pages, until marc pointed me out
> > that you can do the same with xinclude. When I changed to xinclude
> > (passing
> > the URI as a variable) I had the impression that it all went just a
little
> > faster (Or was I just thinking slower;-). Maybe it's worth a try, it's
> > easy
> > to set up and may give a better result. (just one page, pass your uri
and
> > use the xinclude transformer)
> >
> > Cheers,
> >
> > Jan
> >
> > ----- Original Message -----
> > From: "Jorg Heymans" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, January 19, 2004 2:22 PM
> > Subject: slow pipeline (svg, aggregation)
> >
> >
> > > You can tell my problem from this line in the access log:
> > >
> > > INFO (2004-01-19) 14:00.15:336 [access] (/my.svg)
> > > http8080-Processor8/CocoonServlet: 'my.svg' Processed by Apache Cocoon
> > > 2.0.4 in 3.6660166 minutes.
> > >
> > > So one SVG takes about 3.5 minutes to render. Now if i was rendering
the
> > > surface of mars in svg i'ld be happy with this response time. For a
100k
> > > svg file i'm not. On faster machine i get like 50-150 seconds, depends
> > > (on what?)
> > >
> > >
> > > Sitemap.log reveals the delay starts with the contentaggregator
> > >
> > > DEBUG (2004-01-19) 13:56.35:405 [sitemap] (my.svg)
> > > http8080-Processor8/ContentAggregator: ContentAggregator: generating
> > > aggregated content
> > > DEBUG (2004-01-19) 14:00.13:763 [sitemap] (my.svg)
> > > http8080-Processor8/ResourceLimitingPool: Put a
> > > mypackage.CachingRequestGenerator back into the pool.
> > >
> > > Core.log points to the JaxpParser
> > >
> > > DEBUG (2004-01-19) 13:56.35:406 [core.manager]
> > > (/app/cod/12L0101GE/render/heart_ginko_22_132x176.svg)
> > > http8080-Processor8/ResourceLimitingPool: Got a
> > > org.apache.avalon.excalibur.xml.JaxpParser from the pool.
> > > DEBUG (2004-01-19) 14:00.13:739 [core.manager] (my.svg)
> > > http8080-Processor8/ResourceLimitingPool: Put a
> > > org.apache.avalon.excalibur.xml.JaxpParser back into the pool.
> > >
> > > My pipeline is an aggregated one
> > >
> > > <map:match pattern="*/render/*.svg">
> > > <map:aggregate element="aggregation">
> > > <map:part src="file://{1}/{2}.svg"/>
> > > <!-- we need this part because of the aggregator caching bug -->
> > > <map:part
> > >
> >
>
src="cocoon:/aggregate/{2}.svg?p1={request-param:param01}&p2={request-pa
> >
>
ram:param02}&p3={request-param:param03}&p4={request-param:param04}&a
> >
>
mp;p2={request-param:param05}&p2={request-param:param05}&p6={request
> >
> -param:param06}&p7={request-param:param07}&p8={request-param:param
08
> > }&p9={request-param:param09}&p10={request-param:param10}"/>
> > > </map:aggregate>
> > > <map:transform src="stylesheets/make_svg.xsl"/>
> > > <map:serialize type="svg2png"/>
> > > </map:match>
> > >
> > > <map:match pattern="aggregate/*.svg">
> > > <map:generate type="cachingrequest"/>
> > > <map:serialize type="xml"/>
> > > </map:match>
> > >
> > >
> > > Thoughts?
> > > Jorg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> --
> HAKUNA MATATA !!!
>
> +++ GMX - die erste Adresse f�r Mail, Message, More +++
> Bis 31.1.: TopMail + Digicam f�r nur 29 EUR http://www.gmx.net/topmail
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
