cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [C2]: Status report on caching - update
Date Wed, 11 Apr 2001 13:00:58 GMT
Quoting Carsten Ziegeler <>:

> Hi Cocooners,
> let's do a "Calling all stations"...
> the first caching implementation is just finished! 
> Try it out and simply have fun.
> For the caching to work you have to set up the CachingEventPipeline
> in the cocoon.xconf as the EventPipeline.
> The first tests for the welcome, the html, voxml and pdf pages
> where delivered from the cache between 4-6 times faster than fresh
> generated.


I've dropped everything I was doing only to test it!

It's really cool. The overhead the SAX "tee"ing has is rawly about 10-20% on the 
first request (well, I've not done very carefull test so far). Afterward it 
speeds up easily about 5 times. 

Don't worry but :) I've had an error when I was requesting the jakarta site in 
the samples (no data). 

It's a great start for it. Well done, Carsten.

> Concept
> -------
> The concept of the caching is based on the various discussions and
> my own thoughts...So here only a short overview:
> The sitemap components (currently Generator and Transformer) can
> implement the Cacheable interface. This interface has two method:
> - generateKey() to generate a unique key within the space of the
>   component ,e.g for the FileGenerator this key is a hash of the
>   source argument.
>   (For this I added the HashUtil class which provides the BuzHash
>    algorithm).
> - generateValidity() the validity which checks if the cached content
>   is still valid, e.g. for the FileGenerator this is the TimeStamp
>   of the xml file.
> The Caching Algorithm now checks all pipeline components for 
> the Cacheable interface and builds a unique key from these Components
> (starting from the generator just to the point before the first not
> Cacheable component).
> This key is used to get a CachedObject from the EventCache (actually
> a Store). The CachedObject (if available) contains the cached content
> and all validity objects when this was cached.
> The next stage compares the current validity objects with the cached
> ones. If they are all valid the cached response is used.
> If something failes during this algorithm, a new response is generated
> and this result is cached.
> The storing of the sax events is implemented by two more Avalon
> components
> the XMLSerializer and the XMLDeserializer. I just used Stefano's
> XMLCompiler
> and modified it a little bit.
> "That's all".
> What is left to do (regarding caching)?
> ---------------------------------------
> - Further cleanup of the code (I will do that in the next days)
> - Make more components Cacheable
> - Proove if this concept is sufficient.
> - Check if we still need the cache efficiency algorithm
> - Integrate ContentAggregation 
>   Please explain what me what you need for caching ContentAggregation. 

My latest vision about content aggregation was to have a semantic in the sitemap 
to express which cocoon internal request (represented as EventPipelines) makes 
up the initial content of the page. Those collected (sub) EventPipelines would 
be connected in turn to the main EventPipeline. If those sub EventPipeline can 
act like Generators and express their cachability it could eventually be 
possible to cached it as a hole.

>   I totally ignored this part for the first implementation. I don't use
> any
>   SAXConnectors stuff - as I do not understand the sense of them right
> now.

It's meant as transparent xinclude transformers.

>   But I am sure that together, we can solve this.

I'm very confident :)

> We should solve this all in the next week.

I've planned to work tomorow on the CA stuff.

> Wish you all a happy easter!

Same to you.


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

View raw message