Faciliatating profile use (Re: Fixing a Howto)

[Ross Gardler <rg...@apache.org>]

David Crossley wrote:
> Ferdinand Soethe wrote:
> 
>>Ross Gardler wrote:
>>
>>
>>>>It's not actually what I was looking for (Which was a mechanism of
>>>>logging the way of requests through a sitemap as a way of debugging
>>>>them; would have been very useful for my current html-problem).
>>
>>>I think the profiler does that - I've never played with it but David and
>>>Ron have done some work with it.
>>
>>Hmmm. That's interesting. I'll try and figure out how to run that to
>>follow my html-processing.
> 
> 
> There is various discussion in the mail archives.
> Most of it arises due to investigating
> http://issues.apache.org/jira/browse/FOR-572
> 
> A while ago i documented how to use it here:
> http://forrest.apache.org/docs_0_80/howto/howto-dev.html#debug
> 
> It was praised here:
> http://marc.theaimsgroup.com/?t=112650986400002
> Re: Using the Cocoon sitemap profiler
> 
> If you have any observations to add, then please
> add to that thread or the xdoc.
> 
> I cannot suitably stress how useful it is as a
> development tool.

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.

We could later enhance this by adding a command line switch to run with 
the profiler enabled.

In addition to making it easier to run the profiler, it will also keep 
the sitemaps a little more tidy.

Ross

Re: Faciliatating profile use (Re: Fixing a Howto)

[Ross Gardler <rg...@apache.org>]

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

Re: Faciliatating profile use (Re: Fixing a Howto)

[David Crossley <cr...@apache.org>]

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.

-David

> > We could later enhance this by adding a command line switch to run with
> > the profiler enabled.
> 
> > In addition to making it easier to run the profiler, it will also keep
> > the sitemaps a little more tidy.
> 
> And forrest-core.xconf and lib/core, too, but only slightly.
> 
> Ron
> 

Re: Faciliatating profile use (Re: Fixing a Howto)

[Ross Gardler <rg...@apache.org>]

Ron Blaschke wrote:
> Ross Gardler wrote:
> 
>>Ron Blaschke wrote:
>>
>>>Ross Gardler wrote:
>>>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?
> 
> 
>>An internal plugin sitemap gets mounted before anything else is done. So
>>you can indeed make an internal plugin be both input and output as well
>>as internal. It is easy to break everything with internal plugins, much
>>harder with input and output plugins.
> 
> 
> Good, so this shouldn't be too hard, either.
> 
> 
>>Today is Forrest-Tuesday [1] you can find us on irc.freenod.org #for-oct
>>if you need any pointers.
> 
> 
> The one thing left that keeps me from getting started is that I don't
> know how to contribute the plugin.  I don't have any commit rights to
> Forrest, so I guess I am limited to (1) create an issue and attach my
> changes there, or (2) host the plugin myself.  The names would be
> org.apache.forrest.plugin.internal.cprofile or
> org.rblasch.forrest.plugin.internal.cprofile, respectively.

Ron and I are discussing this on IRC, you can see the logs at 20:09 
(http://casa.che-che.com/~bot/forrest/forrest.log.04Oct2005)

This includes the idea of making this profiling plugin into a wider 
ranging test plugin. Worth a read (or contribution if you are around at 
the right time).

Ross

Re: Faciliatating profile use (Re: Fixing a Howto)

[Ron Blaschke <ma...@rblasch.org>]

Ross Gardler wrote:
> Ron Blaschke wrote:
>> Ross Gardler wrote:
>> 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?

> An internal plugin sitemap gets mounted before anything else is done. So
> you can indeed make an internal plugin be both input and output as well
> as internal. It is easy to break everything with internal plugins, much
> harder with input and output plugins.

Good, so this shouldn't be too hard, either.

> Today is Forrest-Tuesday [1] you can find us on irc.freenod.org #for-oct
> if you need any pointers.

The one thing left that keeps me from getting started is that I don't
know how to contribute the plugin.  I don't have any commit rights to
Forrest, so I guess I am limited to (1) create an issue and attach my
changes there, or (2) host the plugin myself.  The names would be
org.apache.forrest.plugin.internal.cprofile or
org.rblasch.forrest.plugin.internal.cprofile, respectively.

Any thoughts?

 >> 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.

> Hmmm... that's an interesting one. I don't think we can make the CLI 
> process pages in a particular order, although I may be wrong.

I've tried adding the profile page as arg to ...cocoon.Main after
${project.start-uri} in main/targets/site.xml, and this seemed to
work.  If by design or accident I don't know.
So it might actually be a good fit to enable profiling via a command
line option.

Ron

Re: Faciliatating profile use (Re: Fixing a Howto)

[Ross Gardler <rg...@apache.org>]

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?

An internal plugin sitemap gets mounted before anything else is done. So 
you can indeed make an internal plugin be both input and output as well 
as internal. It is easy to break everything with internal plugins, much 
harder with input and output plugins.

Today is Forrest-Tuesday [1] you can find us on irc.freenod.org #for-oct 
if you need any pointers.

 > 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.

Hmmm... that's an interesting one. I don't think we can make the CLI 
process pages in a particular order, although I may be wrong.

If we can't do that then we could add Anteater or WebTest to the block 
and have some standard profiling scripts.

Ross

[1] http://forrest.apache.org/forrest-tuesday.html

Re: Faciliatating profile use (Re: Fixing a Howto)

[Ron Blaschke <ma...@rblasch.org>]

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.

> We could later enhance this by adding a command line switch to run with
> the profiler enabled.

> In addition to making it easier to run the profiler, it will also keep
> the sitemaps a little more tidy.

And forrest-core.xconf and lib/core, too, but only slightly.

Ron