Optimizing the document rendering pipelines

[Andreas Hartmann <an...@apache.org>]

Hi Lenya devs,

I'm currently trying to understand the caching mechanisms of the various 
Cocoon pipeline components. It occured to me that our approach to render 
the page doesn't leverage these opportunities at all.

We basically build the page like this:

1. Aggregate content and nav elements.
2. Apply a complex page2xhtml transformation.
3. Apply some other transformations (i18n, proxy etc.).

No single step in this line can be cached, because already at step 1 an 
action is used to determine if the document exists and fetching the 
content requires a call to the resource-type input module. Step 2 uses 
various input modules, so caching is out of the question.

How about this instead:

Pipeline A

1. Generate a static template with include statements for the
    nav elements.
2. Apply the include transformation.
3. Apply a complex page2xhtml transformation without any parameters
    which are based on input modules. Add an include statement to fetch
    the document content into the SAX stream.

Pipeline B

1. Call pipeline A.
2. Apply the include transformation to fetch the document content.
3. Apply another transformation which needs input module params.
4. Apply the rest of the transformations (proxy etc.)


The output of pipeline A can be cached, because it doesn't contain any 
dynamic information. If the transformation A.3 depends on the resource 
type, we can include the resource type name in the cocoon:/ URI so that 
it will be a part of the cache key.

WDYT? I'll try to do a proof of concept on the weekend.

-- Andreas


-- 
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: Optimizing the document rendering pipelines

[Andreas Hartmann <an...@apache.org>]

Andreas Hartmann schrieb:

[...]

> How about this instead:
> 
> Pipeline A
> 
> 1. Generate a static template with include statements for the
>    nav elements.
> 2. Apply the include transformation.
> 3. Apply a complex page2xhtml transformation without any parameters
>    which are based on input modules. Add an include statement to fetch
>    the document content into the SAX stream.
> 
> Pipeline B
> 
> 1. Call pipeline A.
> 2. Apply the include transformation to fetch the document content.
> 3. Apply another transformation which needs input module params.
> 4. Apply the rest of the transformations (proxy etc.)
> 
> 
> The output of pipeline A can be cached, because it doesn't contain any 
> dynamic information. If the transformation A.3 depends on the resource 
> type, we can include the resource type name in the cocoon:/ URI so that 
> it will be a part of the cache key.

I did this little exercise during the weekend. Actually it can be cached 
up to B.2. The resource-exists selection doesn't prevent the pipeline 
from being cached.

I found a workaround for the MultiSourceValidity problem, but discovered 
another one. I added another patch to 
https://issues.apache.org/jira/browse/COCOON-2166.

With my PowerBook I get about 3-4 req/sec in the live area of the 
example publication now.

-- Andreas




-- 
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org