On 2/9/06, Thorsten Scherler <[EMAIL PROTECTED]> 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
