cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: Parallel content-aggregation
Date Wed, 14 Nov 2001 05:37:06 GMT
On Tue, 13 Nov 2001 10:52:17 -0500, Berin Loritsch <> wrote:

> wrote:
> > Hello,
> > 
> > are there any thoughts about a parallel version of content-aggregation ?
> > It would be fine to know something about the pro, cons, and future plans
> > or if help is needed ;^)
> What you are refering to is a very complex beast--especially when it comes
> to ordering the SAX events.  For instance, let's assume we have the following
> structure:
> <map:aggregate>
>    <map:part src="cocoon://foo.xml"/>
>    <map:part src="cocoon://bar.xml"/>
>    <map:part src="cocoon://baz.xml"/>
> </map:aggregate>
> The aggregation engine would be receiving SAX events from all three
> pipelines simultaneously.  As a result the start and end element
> tags would be intermixed.  this is clearly bad.  The alternative is
> to cache the results of the sub pipelines until they are needed.
> However, the current cache mechanism already does this!  So the only
> REAL benefit will be on the first access to the resource in
> question.  Concidering all the complexities involved, the
> synchronization issues, and the overhead of threads (since we
> already have to use one thread per connection); the effort involved
> to buy what is in essence 10-20ms/part[2+] really isn't worth it.
> In the above example, the first part doesn't save any time, but the
> second two may.  In essence the overall speed benefit will be
> 20-40ms.  Even then, I am estimating that it would be closer to only
> 20ms.  Especially if the second part is shorter than the first part!
> Beleive me, I thought about this in detail.  I just don't see how
> the benefit outweighs the costs.

This is correct, except when the requests actually take longer to
execute. If they actually take a lot longer, as when you're sending
requests to a remote Web site, or when the processing involves complex
stylesheet manipulations or what not, it makes sense to spawn multiple
requests in parallel. Especially if you have a beefy machine, with
lots of processors.

Ovidiu Predescu <> (inside HP's firewall only) (my SourceForge page) (GNU, Emacs, other stuff)

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

View raw message