forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: [jira] Commented: (FOR-803) Profile new dispatcher plugins
Date Thu, 09 Feb 2006 12:08:33 GMT
On 2/9/06, Thorsten Scherler <thorsten.scherler@wyona.com> wrote:
> 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.

To both of you... Are these the documented issues or new ones?  If
it's for FOR-732, for development purposes, just turn lm caching off
in forrest-core.xconf for now.

Actually, if I hear no complaints, I'll turn it off by default until
FOR-732 is resolved.

--tim

Mime
View raw message