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:param08
> }&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]
