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 forrest.properties.
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.
STATUS
------
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.
Ross
