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 Homeijer <M....@devote.nl> on 2002/01/02 11:03:15 UTC
Cocoon scalability continued
Hi,
This mail is a follow-up to the following mails:
(Cocoon 2 RC2 performance disappointment).
http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg06455.html
and
(Cocoon 2.0 Scalability Disappointment)
http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg06751.html
In the last weeks we observed that Cocoon performance and scalability are
greatly influenced by a number of factors, to name a few:
- Complexity of pipelines (slows down pipeline composition)
> Stefano mentioned to me that entire pipelines can be pooled.
> Can anybody give me some directions on how to accomplish this?
- Size of the documents going through the pipeline (slows down translations)
- Size of the documents that will be cached (caching appears to be very time
consuming)
- Number of templates in the XSL translation (xsl tuning is very difficult)
To tune our C2 based site we tried three ways of implementing our website,
all with different approaches. The approach we thought should be the one
with the best performance/scalability turned out worse than the C1
implementation (performance of the three range from several times slower
than the C1 implementation to 10% faster).
Luckily, with the new component approach it was just a few days work (mainly
changing places of caching and XSL translations) to get a better
performance(10% on the C1 approach, and we think we can get further now we
know which strings to pull. Furthermore we didn't try the generator based
approach yet instead of XSP).
But then again, I don't think every project will get this far...
and I think that new versions of Cocoon will show a very different
performance/scalability profile (once the new cache,
sitemap approach or new Xalan versions are released), this could also be
dangerous without some sort of performance prediction model.
In the weeks we tried to tune our C2 based site, we went from designing and
implementing to a more trial and error approach in configuring the
pipelines. Because of the unpredictable results (because of complexity or
lack of experience on our side?) and the pressure from our customer the team
spirit went down. Furthermore it's hard to derive best practices or some
golden rule from our work.
Because of this I think it is not enough to have a cache that tunes itself
or a profiler. It will help but only once your site is up and running.
Because of the many ways of implementing a C2 site, I think there should be
some kind of prediction model that shows how to structure functionality in
C2.
I don't have a clear idea on what this should look like, but maybe someone
can comment on our experiences.
TIA,
Michael Homeijer.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon scalability continued
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Michael Homeijer wrote:
>
>>Hi,
>>
>>This mail is a follow-up to the following mails:
>>
>>(Cocoon 2 RC2 performance disappointment).
>>http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg06455.html
>>
>>and
>>
>>(Cocoon 2.0 Scalability Disappointment)
>>http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg06751.html
>>
>>In the last weeks we observed that Cocoon performance and scalability are
>>greatly influenced by a number of factors, to name a few:
>>- Complexity of pipelines (slows down pipeline composition)
>> > Stefano mentioned to me that entire pipelines can be pooled.
>> > Can anybody give me some directions on how to accomplish this?
>>
> Do you mean pooled? AFAIK this is not possible. Complete pipelines can
> be cached but not pooled.
It would be possible with a different implementation of Pipeline and useage
model for the pipelines. IMO, the development of this change would be worth
it.
The change does not favor the current method of generating pipelines, but then
again, it would have to be rewritten.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon scalability continued
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Michael Homeijer wrote:
>
> Hi,
>
> This mail is a follow-up to the following mails:
>
> (Cocoon 2 RC2 performance disappointment).
> http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg06455.html
>
> and
>
> (Cocoon 2.0 Scalability Disappointment)
> http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg06751.html
>
> In the last weeks we observed that Cocoon performance and scalability are
> greatly influenced by a number of factors, to name a few:
> - Complexity of pipelines (slows down pipeline composition)
> > Stefano mentioned to me that entire pipelines can be pooled.
> > Can anybody give me some directions on how to accomplish this?
Do you mean pooled? AFAIK this is not possible. Complete pipelines can
be cached but not pooled.
Carsten
>
> - Size of the documents going through the pipeline (slows down
> translations)
> - Size of the documents that will be cached (caching appears to
> be very time
> consuming)
> - Number of templates in the XSL translation (xsl tuning is very
> difficult)
>
> To tune our C2 based site we tried three ways of implementing our website,
> all with different approaches. The approach we thought should be the one
> with the best performance/scalability turned out worse than the C1
> implementation (performance of the three range from several times slower
> than the C1 implementation to 10% faster).
>
> Luckily, with the new component approach it was just a few days
> work (mainly
> changing places of caching and XSL translations) to get a better
> performance(10% on the C1 approach, and we think we can get further now we
> know which strings to pull. Furthermore we didn't try the generator based
> approach yet instead of XSP).
>
> But then again, I don't think every project will get this far...
>
> and I think that new versions of Cocoon will show a very different
> performance/scalability profile (once the new cache,
> sitemap approach or new Xalan versions are released), this could also be
> dangerous without some sort of performance prediction model.
>
> In the weeks we tried to tune our C2 based site, we went from
> designing and
> implementing to a more trial and error approach in configuring the
> pipelines. Because of the unpredictable results (because of complexity or
> lack of experience on our side?) and the pressure from our
> customer the team
> spirit went down. Furthermore it's hard to derive best practices or some
> golden rule from our work.
>
> Because of this I think it is not enough to have a cache that tunes itself
> or a profiler. It will help but only once your site is up and running.
> Because of the many ways of implementing a C2 site, I think there
> should be
> some kind of prediction model that shows how to structure functionality in
> C2.
>
> I don't have a clear idea on what this should look like, but maybe someone
> can comment on our experiences.
>
> TIA,
> Michael Homeijer.
>
>
>
>
> ---------------------------------------------------------------------
> 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