cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@infoplanning.com>
Subject Re: [RT] Cocoon in cacheland
Date Tue, 28 Nov 2000 19:17:43 GMT

----- Original Message ----- 
From: "Stevenson, Chris (SSABSA)" <chris@ssabsa.sa.gov.au>
To: <cocoon-dev@xml.apache.org>
Sent: Monday, November 27, 2000 7:47 PM
Subject: RE: [RT] Cocoon in cacheland


> > I think *now* is the time to start a discussion on it however,
> > because before anyone (be it me or anyone else) starts implementing
> > the caching architecture, we need to have worked out some of
> > the technical details.
> 
> Hear hear!
> 
> I remember Stefano's original post, and I appreciate this as 
> well, but I am left with a nagging doubt. This is, no-one
> has convinced me that we need 'Internal Caching'.

If you are referring to Component Pooling, then I beg to differ.
Any object that will see heavy use should be pooled: instead of
having 100 different threads handling 100 different users, Cocoon
should employ the approach of pooling Sitemaps, Parsers, InputSources,
Transformers, and Serializers.

What is the point of all this pooling, if we can't have cached
implementations of compiled stylesheets and such.  Any serious
web server will have lots of memory, so here is where I see
potential payoffs:

1) Generators are cached and pooled (in otherwords, certain
   files will be accessed often--two concurrent requests shouldn't
   force you to wait.
2) The stylesheet is compiled and pooled.  This is a point of
   high contention, because there are few stylesheets to many
   Generators (this is assuming good web design).  The transformers
   must be pooled.
3) Serializers are pooled -- There should be even fewer Serializers
   than stylesheets assuming you have a large site or narrow focus.
   As a result you can expect _several_ HTML requests simultaneously.
   Sharing one serializer among several requests only exacerbates
   the problem of latencies.

Now you might interject that it is easier to generate these resources
than pool them.  We need to be reminded that garbage collection is
costly.  If we can avoid the garbage collection as much as possible,
then we have acheived our goal.  Many of these objects are heavy
in that they take more time to instantiate and configure than they
do to reuse.  By pooling the components, we have as many instances
as are simultaneously needed for good traffic flow.

As Cocoon2 stands now, it is not highly scalable--and pooling and
caching techniques will change that.  Yes we need to cache the final
results of our entire pipeline--but that does not help the intermediary
steps.


Mime
View raw message