forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Faciliatating profile use (Re: Fixing a Howto)
Date Wed, 05 Oct 2005 09:56:14 GMT
David Crossley wrote:
> Ron Blaschke wrote:
>>Ross Gardler wrote:
>>>David, I am afraid to say I have not checked this out yet. Despite
>>>noting its existence and the effort you put into this (and the docs).
>>>Can I make a suggestion? (I'll do this the first time I find the need to
>>>use this if it hasn't been done before me):
>>>If we make an internal plugin of the profiler we can replace the 
>>>necessary pipelines in that plugin. Then, to enable profiling all we 
>>>need to do is add the plugin to
>>I am about to start working on a plugin.  Actually, I thought I
>>could start last weekend, but didn't quite make it.
>>Most things are straightforward.  I'm only puzzled by the mix of input
>>plugin (ie, take data from the profiler data store and render it) and
>>internal plugin (ie, profile stuff and store results in profiler data
>>store).  Can a plugin be both, input and internal?
>>Second, the profiler result page must be rendered last, or it wouldn't
>>contain all profile results.  Don't know how to do this, yet.
> I find that the Cocoon Profiler is useful to look at the
> processing for a single page, i.e. forrest clean, forrest run,
> request index.html a few times, then look at cprofile.html
> and follow the results. Doing it for the whole of 'forrest site'
> might be useful in a different way - don't know yet.

Ron and I talked about this on IRC (see logs). I suggested making the 
profiler block a dobule purpose block - profiling and testing. Ron 
pointed me to your past discussions regarding benchmarking.

After discussion it became apparrent that making ait a test block as 
well was not a good idea (tests change often, profling/benchmarking need 
  stable content to work on).

To profile Forrest effectively we need to profile all paths through the 
pipelines. To benchmark we need to do it a number of times.

I think that having benchmark sites that has pages designed to test 
various paths (perhaps plugins can provide additional benchmark pages in 
the future) is a very good idea. We could run Forrest on these sites, 
say 1000 times. This would give us a reasonable indication (given 
consistent server spec) of whether a new release is performing well or not.

Of course, profiling individual pages is useful for testing individual 
edits. This would still be useful in the way you describe.


Ron has the skeleton together, but has hit a problem. The internal.xmap 
needs to redefine the <map:pipe> elements, which can't be done - or so 
we thought on IRC. But I never thought to ask Ron if he had "just tried 
it". ROn, if you didn't try it please do, I remember reading that blocks 
can now define their own component specifications, perhaps it will work 
for mounted sitemaps too.

Ron is exploring this with Cocoon folk.


View raw message