forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [jira] Commented: (FOR-803) Profile new dispatcher plugins
Date Thu, 09 Feb 2006 11:55:06 GMT
El jue, 09-02-2006 a las 10:57 +0000, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El jue, 09-02-2006 a las 18:27 +1100, David Crossley escribió:
> > 
> >>I started doing some "Cocoon Profiler" on site-author.
> >>Processing index.html four times then looking at cprofile.html
> >>
> >>Compared Dispatcher-enabled site-author with the profile
> >>of skins-based site-author running on another port.
> >>
> >>Still not sure how to interpret results, but
> >>here are some initial observations.
> >>
> >>Using the default theme ...
> >>
> >>Some pipelines seem to be requested twice or more
> >>for each page view, e.g.
> >>resolve.contract.html.siteinfo-feedback
> > 
> > 
> > Yes, that is how the dispatcher is working so far. As soon as you use
> > twice a contract it will be included twice and requested twice. 
> Hmmm.... siteinfo-feedback needs to be called twice because it is used 
> twice. OK - can't avoid that, but we can cache the results in most 
> instances. More below...

Yes, some contracts can be cached others not that easy. Since contracts
are beans we should take advantages of it. Right now we create on
instance of the bean and reuse it by this.contract.recycle(); which
flashes the contract. 

Maybe it make more sense to keep different bean instances in a pool
while processing the request and then if processing ends we flash the
pool. That makes it possible to look up the bean instance from the pool
and reuse it if the bean exist in the pool.

The challenge is to have well defined bean identifier since we have to
keep in mind that if the dataURI is changing we need to set the rawData
again. Further the contract properties need sometimes as well an update
of the bean.

> >>Total of about 100 pipelines were processed compared
> >>with about 45 pipelines for the skins-based site
> >>and about 40 pipelines for the default dispatcher site.
> >>
> > 
> > 
> > The idea is that contracts are standalone and self containing that has
> > the downside that some information are requested more then once. I am
> > unsure how we can reuse the pipes more efficient since I reckon they
> > cause the build time to rise. Maybe we should think about a dispatcher
> > generator that will request the dataUri and aggregates the data
> > requested by the structurer. From there we can request this data from
> > the dispatcher transformer. That would help controlling that contracts
> > (if using the same dataUri) would use only *one* pool (aggregated by the
> > dispatcher generator) and the data get requested *only once*.
> > 
> > wdyt?
> Eactly what I was thinking...
> I'm afraid I'm still not able to work on the Dispatcher, however I have 
> a site I am currently working on the back end for and want to use 
> dispatcher on the front end. So as soon as the backend is working 
> sufficiently I will be looking into the dispatcher in detail. 
> Performance is the key for me as the application wil be a dynamic one.

Looking forward to it. ;-)

> Unfortunately this means I have to solve some issues with the 
> locationmap cache first.

Yes, I am running ATM as well constantly into caching issues with the
locationmap. I thought about a non cached locationmap lookup pipe that
will force the locationmap to not use the cache for location lookups.

Thorsten Scherler
COO Spain
Wyona Inc.  -  Open Source Content Management  -  Apache Lenya               

View raw message