cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Petrie <>
Subject Re: Caching of aggregate parts
Date Wed, 06 Aug 2003 08:59:51 GMT

You are right.  map:aggregate does indeed support caching.  I tested an 
aggregation of filetransformers and I see the cache key in the 
infostore.  I narrowed my map:aggregate problems down to be a call to a 
cocoon:/ pipeline that uses CInclude which is the source of my 
performance issues.


On Tuesday, Aug 5, 2003, at 13:16 Europe/Berlin, Geoff Howard wrote:

> Darren Petrie wrote:
>> I have a similar situation with my site both with the use of 
>> map:aggregate and cinclude.  It seems the individual parts of the 
>> aggregation cache but not the aggregation as a whole.  Similarly with 
>> Cinclude.  I am using a fo2pdf serializer which can be fairly slow.  
>> So with the aggregation not caching it doesn't cache the serializer.  
>> I am getting killed with performance and am looking at ways to kludge 
>> around it.
>> Darren
> Hmmm.  I haven't looked (and can't ATM) into how map:aggregate handles 
> its caching, but I'm surprised it isn't allowing the whole pipeline to 
> be cached.  Can you send a sample of this pipeline too?
> Geoff
>> On Tuesday, Aug 5, 2003, at 00:11 Europe/Berlin, Geoff Howard wrote:
>>> Justin Makeig wrote:
>>>> <map:match pattern="initiatives/*/">
>>>>  <map:aggregate element="Page">
>>>>    <map:part src="xml/toc.xml"/>
>>>>    <map:part src="xml/site/initiatives/{1}.xml"/>
>>>>   </map:aggregate>
>>>>   <map:transform src="xsl/xhtml/initiatives/initiative.xsl">
>>>>   <map:parameter name="requesturi" value="/initiatives/{1}/"/>
>>>>  </map:transform>
>>>>   <map:serialize type="xhtml"/>
>>>> </map:match>
>>> This looks cacheable to me, unless I'm crazy and map:aggregate 
>>> doesn't support caching  at all.  It should already be cached by 
>>> default.  If you still have the samples running, check the status 
>>> page and see if there is a pipeline key that looks like it matches.  
>>> It's not entirely clear, but you should be able to make some 
>>> intelligent guesses.
>>> Of course this may be bad news if you are not getting good 
>>> performance from it.  If you turn logging all the way up to debug 
>>> you should be able to see a processing time difference between its 
>>> first request (after clearing the cache(s) or requesting with a new 
>>> unique value of {1}
>>> Geoff
>>>>> Justin Makeig wrote:
>>>>>> I have a table of contents (TOC) document that is being 
>>>>>> aggregated with an
>>>>>> XML instance document for each page request. For example, when
>>>>>> is requested, the sitemap aggregator 
>>>>>> generates a
>>>>>> document that looks like:
>>>>>> <Page>
>>>>>>    <TOC/>
>>>>>>    <Instance/>
>>>>>> </Page>
>>>>>> where TOC and Instance are loaded from the file system using
>>>>>> map:aggreate/map:part.
>>>>>> This system allows me to use XSL keys instead of the document 
>>>>>> function to
>>>>>> reference elements in the TOC making the transforms speedy and 
>>>>>> cacheable.
>>>>>> The TOC document is around 50K and growing arithmetically. Since

>>>>>> the TOC is
>>>>>> generated at design-time (not run-time), I would like to cache it

>>>>>> so that it
>>>>>> doesn't have to reparsed for every request. Is this possible? Is

>>>>>> it already
>>>>>> being done with map:aggregate? Any assistance would be much 
>>>>>> appreciated.
>>>>> Can you send your sitemap snippet that does the aggregation?
>>>>> Geoff
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
Darren Petrie

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message