You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Michael Melhem <mi...@fztig938.bank.dresdner.net> on 2002/06/13 13:20:03 UTC
[PROPOSAL] "CachingPoint" Caching algorithm
Hi all,
I have started work on new caching algoritm which is refered to as
the "cachingPoint" alogrithm.
The developer can configer certain pipelines to use this alogrithm as
required. The cahingPoint algorithm is of best value when a pipeline uses lots
"cocoon-views" or selectors or contains drill-down functionality
The idea of cache points is instead of simply caching the longest
possible key in a given pipeline, we also strategically cache points along the way.
When building a pipeline, we mark as "cachepoint" the last component in
the pipeline if next component needs to be chosen from a set of
possible components (ie we come a cross a branch or fork in the process tree)
Tha advanatge of this algorithm is that common segments of a pipeline are cached
ready for reuse.
Perhaps the basic idea can be best illustrated with a very simple
example.
Consider the following sitemap:
<map:view name="content" from-label="content">
<map:serialize type="xml"/>
</map:view>
<map:match pattern="welcome">
<map:generate src="samples.xml" label="content"/>
<map:transform src="common/style/xsl/html/simple-samples2html.xsl"/>
<map:serialize type="html"/>
</map:match>
For the the request:/welcome the default caching algorithm would cache a
single cache entry using key determined by the
generator+transformer+HTMLserializer: PCK:CCK:1file:CCK:3xsltCCK:5html
When we fire of the request:/welcome?cocoon-view=content, the default
algorithm would look up the cache for the key: PCK:CCK:1file:CCK:5xml
(determined by generator+XMLserializer) and find nothing. Even though
we are generating the exact same information, this information is not cached.
The proposed caching alagorithm would resolve this issue by caching along side
the full result, the result of the generator as well. This is because the
generator would be designated as a "cachepoint" in this case.
Feedback is welcome.
Best Regards,
Michael Melhem
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] "CachingPoint" Caching algorithm
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Michael Melhem [mailto:michaelm@fztig938.bank.dresdner.net]
<snip/>
> > > That's a clever algorithm, but don't you fear it will create too
many
> > > branch points (and so cache entries) that what is really required
by
> > > the application ?
> >
> > Same fear here.
>
> The idea is that whenever the developer feels that cachingpoints would
> be beneficial (perhaps in the case where they use cocoon-views or
drill down
> functionality heavily in a pipleline) then they can set that pipeline
> and *only* that pipleine to use caching points.
>
> <map:pipelines default="caching">
> <map:pipeline name="caching"
>
src="org.apache.cocoon.components.pipeline.impl.CachingProcessingPipelin
e"/>
> <map:pipeline name="cachingpoint"
>
src="org.apache.cocoon.components.pipeline.impl.CachingPointProcessingPi
peline
> "/>
> </map:pipelines>
>
> Cocoon 2.1 allows one to select the pipeline caching algorithm as
above.
>
> This means that the effect of cachingpoint algorithm is localised to
where
> its needed.
I know this, and CachingPointProcessingPipeline may be useful in some
situations.
> > PS What was the reason against <map:cache/> proposal in the early
days
> > of C2? It seems a bit similar to this caching point stuff.
>
> Im not sure how <map:cache> worked....hmmm, but with cachingpoint
> the caching points are *implicitly* loacted *only* at strategic points
> through out the pipeline, and only if that particular pipeline is
> set to cachingpoint itself.
It never worked, it was proposed once. The idea was to allow developer
to specify caching points.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] "CachingPoint" Caching algorithm
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Mon, Jun 17, 2002 at 09:41:40AM -0400, Vadim Gritsenko wrote:
> > From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> >
> > Michael Melhem wrote:
> >
> > >Hi Sylvain,
> > >
> > >You will find my response to your comments below.
> > >
> > >On Mon, Jun 17, 2002 at 02:05:33PM +0200, Sylvain Wallez wrote:
> > >
> > >>Michael Melhem wrote:
>
> <snip/>
>
> > >>That's a very interesting proposal, as it can speedup a lot
> > >>multi-channel applications. However, you forgot to say how do you
> flag a
> > >>sitemap component as being a cache point ?
> > >>Does it require a specific attribute (<map:generate src="foo.xml"
> > >>cachepoint="true"/>) ?
> > >>Can it be related to view labels (<map:view name="foo"
> > >>from-label="foolabel" cachepoint="true") ?
> > >>
> > >
> > >Actually, cachepoint points are determined automatically
> > >using the following algorithm:-
> > >
> > >In Pseudo code the basic idea is as follows:
> > >if current Node extends SimpleSelectorProcessingNode
> > > and if context.getProcessingPipeline() != null
> > >
> context.getProcessingPipeline().informBranchPoint()
> > >
> > >In other words, as we build up the pipeline (via invoke()),
> > >whenever we come across treeprocessor nodes which
> > >extend SimpleSelectorProcessingNode, then that should indicate
> > >to us that a CachingPoint should be flagged
>
> <snip/>
>
> > That's a clever algorithm, but don't you fear it will create too many
> > branch points (and so cache entries) that what is really required by
> the
> > application ?
>
> Same fear here.
The idea is that whenever the developer feels that cachingpoints would
be beneficial (perhaps in the case where they use cocoon-views or drill down
functionality heavily in a pipleline) then they can set that pipeline
and *only* that pipleine to use caching points.
<map:pipelines default="caching">
<map:pipeline name="caching"
src="org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline"/>
<map:pipeline name="cachingpoint"
src="org.apache.cocoon.components.pipeline.impl.CachingPointProcessingPipeline"/>
</map:pipelines>
Cocoon 2.1 allows one to select the pipeline caching algorithm as above.
This means that the effect of cachingpoint algorithm is localised to where its
needed.
>
>
> PS What was the reason against <map:cache/> proposal in the early days
> of C2? It seems a bit similar to this caching point stuff.
Im not sure how <map:cache> worked....hmmm, but with cachingpoint
the caching points are *implicitly* loacted *only* at strategic points
through out the pipeline, and only if that particular pipeline is
set to cachingpoint itself.
Regards,
Michael
>
> Vadim
>
>
> > Sylvain
> >
> > --
> > Sylvain Wallez
> > Anyware Technologies Apache Cocoon
> > http://www.anyware-tech.com mailto:sylvain@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] "CachingPoint" Caching algorithm
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Michael Melhem wrote:
>
> >Hi Sylvain,
> >
> >You will find my response to your comments below.
> >
> >On Mon, Jun 17, 2002 at 02:05:33PM +0200, Sylvain Wallez wrote:
> >
> >>Michael Melhem wrote:
<snip/>
> >>That's a very interesting proposal, as it can speedup a lot
> >>multi-channel applications. However, you forgot to say how do you
flag a
> >>sitemap component as being a cache point ?
> >>Does it require a specific attribute (<map:generate src="foo.xml"
> >>cachepoint="true"/>) ?
> >>Can it be related to view labels (<map:view name="foo"
> >>from-label="foolabel" cachepoint="true") ?
> >>
> >
> >Actually, cachepoint points are determined automatically
> >using the following algorithm:-
> >
> >In Pseudo code the basic idea is as follows:
> >if current Node extends SimpleSelectorProcessingNode
> > and if context.getProcessingPipeline() != null
> >
context.getProcessingPipeline().informBranchPoint()
> >
> >In other words, as we build up the pipeline (via invoke()),
> >whenever we come across treeprocessor nodes which
> >extend SimpleSelectorProcessingNode, then that should indicate
> >to us that a CachingPoint should be flagged
<snip/>
> That's a clever algorithm, but don't you fear it will create too many
> branch points (and so cache entries) that what is really required by
the
> application ?
Same fear here.
PS What was the reason against <map:cache/> proposal in the early days
of C2? It seems a bit similar to this caching point stuff.
Vadim
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies Apache Cocoon
> http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] "CachingPoint" Caching algorithm
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Michael Melhem wrote:
>Hi Sylvain,
>
>You will find my response to your comments below.
>
>On Mon, Jun 17, 2002 at 02:05:33PM +0200, Sylvain Wallez wrote:
>
>
>>Michael Melhem wrote:
>>
>>
>>
>>>Hi all,
>>>
>>>I have started work on new caching algoritm which is refered to as
>>>the "cachingPoint" alogrithm.
>>>
>>>
<snip/>
>>That's a very interesting proposal, as it can speedup a lot
>>multi-channel applications. However, you forgot to say how do you flag a
>>sitemap component as being a cache point ?
>>Does it require a specific attribute (<map:generate src="foo.xml"
>>cachepoint="true"/>) ?
>>Can it be related to view labels (<map:view name="foo"
>>from-label="foolabel" cachepoint="true") ?
>>
>>
>
>Actually, cachepoint points are determined automatically
>using the following algorithm:-
>
>In Pseudo code the basic idea is as follows:
>if current Node extends SimpleSelectorProcessingNode
> and if context.getProcessingPipeline() != null
> context.getProcessingPipeline().informBranchPoint()
>
>In other words, as we build up the pipeline (via invoke()),
>whenever we come across treeprocessor nodes which
>extend SimpleSelectorProcessingNode, then that should indicate
>to us that a CachingPoint should be flagged
>
>The cocoon-view case is treated separately. Here is an example from
>GenerateNode.java:
>---------------------------------------------
>...
>if (this.views != null) {
> //
> //
> // Inform the pipeline that we have a branch
> // point
> //
> context.getProcessingPipeline().informBranchPoint();
>
> String cocoonView = env.getView();
> if (cocoonView != null) {
>...
>---------------------------------------------
>
>Note: informBranchPoint() simply does nothing if the selected
>ProcessingPipeline does not support cachepoints
>
>
That's a clever algorithm, but don't you fear it will create too many
branch points (and so cache entries) that what is really required by the
application ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] "CachingPoint" Caching algorithm
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
Hi Sylvain,
You will find my response to your comments below.
On Mon, Jun 17, 2002 at 02:05:33PM +0200, Sylvain Wallez wrote:
> Michael Melhem wrote:
>
> >Hi all,
> >
> >I have started work on new caching algoritm which is refered to as
> >the "cachingPoint" alogrithm.
> >
> >The developer can configer certain pipelines to use this alogrithm as
> >required. The cahingPoint algorithm is of best value when a pipeline uses
> >lots
> >"cocoon-views" or selectors or contains drill-down functionality
> >
> >The idea of cache points is instead of simply caching the longest
> >possible key in a given pipeline, we also strategically cache points along
> >the way.
> >
> >When building a pipeline, we mark as "cachepoint" the last component in
> >the pipeline if next component needs to be chosen from a set of
> >possible components (ie we come a cross a branch or fork in the process
> >tree)
> >
> >Tha advanatge of this algorithm is that common segments of a pipeline are
> >cached
> >ready for reuse.
> >
> >Perhaps the basic idea can be best illustrated with a very simple
> >example.
> >
> >Consider the following sitemap:
> >
> ><map:view name="content" from-label="content">
> > <map:serialize type="xml"/>
> ></map:view>
> >
> ><map:match pattern="welcome">
> > <map:generate src="samples.xml" label="content"/>
> > <map:transform src="common/style/xsl/html/simple-samples2html.xsl"/>
> > <map:serialize type="html"/>
> ></map:match>
> >
> >For the the request:/welcome the default caching algorithm would cache a
> >single cache entry using key determined by the
> >generator+transformer+HTMLserializer: PCK:CCK:1file:CCK:3xsltCCK:5html
> >
> >When we fire of the request:/welcome?cocoon-view=content, the default
> >algorithm would look up the cache for the key: PCK:CCK:1file:CCK:5xml
> >(determined by generator+XMLserializer) and find nothing. Even though
> >we are generating the exact same information, this information is not
> >cached.
> >
> >The proposed caching alagorithm would resolve this issue by caching along
> >side
> >the full result, the result of the generator as well. This is because the
> >generator would be designated as a "cachepoint" in this case.
> >
> >Feedback is welcome.
> >
>
> That's a very interesting proposal, as it can speedup a lot
> multi-channel applications. However, you forgot to say how do you flag a
> sitemap component as being a cache point ?
> Does it require a specific attribute (<map:generate src="foo.xml"
> cachepoint="true"/>) ?
> Can it be related to view labels (<map:view name="foo"
> from-label="foolabel" cachepoint="true") ?
Actually, cachepoint points are determined automatically
using the following algorithm:-
In Pseudo code the basic idea is as follows:
if current Node extends SimpleSelectorProcessingNode
and if context.getProcessingPipeline() != null
context.getProcessingPipeline().informBranchPoint()
In other words, as we build up the pipeline (via invoke()),
whenever we come across treeprocessor nodes which
extend SimpleSelectorProcessingNode, then that should indicate
to us that a CachingPoint should be flagged
The cocoon-view case is treated separately. Here is an example from
GenerateNode.java:
---------------------------------------------
...
if (this.views != null) {
//
//
// Inform the pipeline that we have a branch
// point
//
context.getProcessingPipeline().informBranchPoint();
String cocoonView = env.getView();
if (cocoonView != null) {
...
---------------------------------------------
Note: informBranchPoint() simply does nothing if the selected
ProcessingPipeline does not support cachepoints
>
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies Apache Cocoon
> http://www.anyware-tech.com mailto:sylvain@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
Best Regards,
Michael Melhem
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] "CachingPoint" Caching algorithm
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Michael Melhem wrote:
>Hi all,
>
>I have started work on new caching algoritm which is refered to as
>the "cachingPoint" alogrithm.
>
>The developer can configer certain pipelines to use this alogrithm as
>required. The cahingPoint algorithm is of best value when a pipeline uses lots
>"cocoon-views" or selectors or contains drill-down functionality
>
>The idea of cache points is instead of simply caching the longest
>possible key in a given pipeline, we also strategically cache points along the way.
>
>When building a pipeline, we mark as "cachepoint" the last component in
>the pipeline if next component needs to be chosen from a set of
>possible components (ie we come a cross a branch or fork in the process tree)
>
>Tha advanatge of this algorithm is that common segments of a pipeline are cached
>ready for reuse.
>
>Perhaps the basic idea can be best illustrated with a very simple
>example.
>
>Consider the following sitemap:
>
> <map:view name="content" from-label="content">
> <map:serialize type="xml"/>
> </map:view>
>
> <map:match pattern="welcome">
> <map:generate src="samples.xml" label="content"/>
> <map:transform src="common/style/xsl/html/simple-samples2html.xsl"/>
> <map:serialize type="html"/>
> </map:match>
>
>For the the request:/welcome the default caching algorithm would cache a
>single cache entry using key determined by the
>generator+transformer+HTMLserializer: PCK:CCK:1file:CCK:3xsltCCK:5html
>
>When we fire of the request:/welcome?cocoon-view=content, the default
>algorithm would look up the cache for the key: PCK:CCK:1file:CCK:5xml
>(determined by generator+XMLserializer) and find nothing. Even though
>we are generating the exact same information, this information is not cached.
>
>The proposed caching alagorithm would resolve this issue by caching along side
>the full result, the result of the generator as well. This is because the
>generator would be designated as a "cachepoint" in this case.
>
>Feedback is welcome.
>
That's a very interesting proposal, as it can speedup a lot
multi-channel applications. However, you forgot to say how do you flag a
sitemap component as being a cache point ?
Does it require a specific attribute (<map:generate src="foo.xml"
cachepoint="true"/>) ?
Can it be related to view labels (<map:view name="foo"
from-label="foolabel" cachepoint="true") ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org