cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: slow pipeline (svg, aggregation)
Date Mon, 19 Jan 2004 18:36:40 GMT
Jorg Heymans wrote:

> Why is the svgserializer making an http call to web5.w3.org every time a 
> template is rendered? Would the used doctype be the culprit here?
> 
> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
>     "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">

Look at the "catalog" support in the examples and docs to provide a 
local copy of the dtd.  Yes, this is standard xml behavior - except IIRC 
the mechanism to turn off dtd resolving is somewhat broken in the xml 
libraries most people use (xerces/xalan).

Geoff

> Batik seems quite picky about which doctype to use so i don't have many 
> options here. This could ofcourse explain the random behaviour in 
> rendering times (now they are rendered in about 10-30 seconds).
> 
> Additionally would I need to worry if
> a)i run this in a closed environment ie no external internet available
> b)this w3.org domain goes down
> 
> Is this a general XML feature that can be switched off?
> 
> 
> Jorg
> 
> 
> Jorg Heymans wrote:
> 
>> 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}&amp;p2={request-param:param02}&amp;p3={request-param:param03}&amp;p4={request-param:param04}&amp;p2={request-param:param05}&amp;p2={request-param:param05}&amp;p6={request-param:param06}&amp;p7={request-param:param07}&amp;p8={request-param:param08}&amp;p9={request-param:param09}&amp;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>




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


Mime
View raw message