cocoon profiling

[Sebastian Rosensteiner <se...@gmx.at>]

Hi everyone,

Sebastian here, one of the students working on cocoon-profiling. We are 
about to build a suitable data structure for the profiling data, and we 
are now facing the problem that a lot of data we store is redundant. 
This is because some of our aspects are very generic and intercept calls 
of the same object (e.g. a PipelineComponent) several times, storing the 
same information in several ProfilingData objects. I see no way to make 
the aspects more specific, since we have no information which servlets, 
sitemaps and pipeline components might be used and which methods are called.

Measuring the runtime of servlets, sitemaps and pipeline components is 
now done at a method basis, which means that we have accurate data on 
the runtime of the intercepted methods, but no data on the runtime 
(lifetime) of a specific servlet or pipeline component.

If you have any suggestions or ideas, please let us know!

Sebastian

Re: cocoon profiling

[Joerg Heinicke <jo...@gmx.de>]

On 14.05.2009 13:51, Christoph Leiter wrote:

> Sebastian Rosensteiner wrote:
>> Sebastian here, one of the students working on cocoon-profiling. We 
>> are about to build a suitable data structure for the profiling data, 
>> and we are now facing the problem that a lot of data we store is 
>> redundant. This is because some of our aspects are very generic and 
>> intercept calls of the same object (e.g. a PipelineComponent) several 
>> times, storing the same information in several ProfilingData objects. 
>> I see no way to make the aspects more specific, since we have no 
>> information which servlets, sitemaps and pipeline components might be 
>> used and which methods are called.
>>
>> Measuring the runtime of servlets, sitemaps and pipeline components is 
>> now done at a method basis, which means that we have accurate data on 
>> the runtime of the intercepted methods, but no data on the runtime 
>> (lifetime) of a specific servlet or pipeline component.
> 
> this may sound a bit confusing to everyone not that much involved in 
> this subproject.

I agree :) The bigger picture is needed - or a concrete example.

Joerg

Re: cocoon profiling

[Christoph Leiter <e0...@student.tuwien.ac.at>]

Hello,

Reinhard Pötz wrote:
> I've just applied your patch. Fire at will ;-)

thanks Reinhard.  As the new patch is quite large I made it available at 
<http://christophleiter.com/tmp/cocoon-profiling-1.patch>

We have a dependency on xstream, but this is only for testing purposes 
and will be removed soon.  Also there are many files in COB-INF/ (these 
are copied from cocoon-sample) which we currently use for our unit test. 
  We'll clean them up too after we know how we proceed with testing.

If anyone else is interested in cocoon-profiling this would be a great 
time to have a look at it and give some feedback. :)


Regards
Christoph

Re: cocoon profiling

[Reinhard Pötz <re...@apache.org>]

Christoph Leiter wrote:
> Hi,
> 
> Sebastian Rosensteiner wrote:
>> Sebastian here, one of the students working on cocoon-profiling. We
>> are about to build a suitable data structure for the profiling data,
>> and we are now facing the problem that a lot of data we store is
>> redundant. This is because some of our aspects are very generic and
>> intercept calls of the same object (e.g. a PipelineComponent) several
>> times, storing the same information in several ProfilingData objects.
>> I see no way to make the aspects more specific, since we have no
>> information which servlets, sitemaps and pipeline components might be
>> used and which methods are called.
>>
>> Measuring the runtime of servlets, sitemaps and pipeline components is
>> now done at a method basis, which means that we have accurate data on
>> the runtime of the intercepted methods, but no data on the runtime
>> (lifetime) of a specific servlet or pipeline component.
> 
> this may sound a bit confusing to everyone not that much involved in
> this subproject.  But we are trying to get our code into trunk.  As soon
> as our initial patch [1] gets applied (Reinhard?) we'll provide a second
> patch with actual code so you guys have a better understanding of what
> we are talking about.  I hope some really interesting discussions can
> start from there. :)

I've just applied your patch. Fire at will ;-)

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

Re: cocoon profiling

[Christoph Leiter <e0...@student.tuwien.ac.at>]

Hi,

Sebastian Rosensteiner wrote:
> Sebastian here, one of the students working on cocoon-profiling. We are 
> about to build a suitable data structure for the profiling data, and we 
> are now facing the problem that a lot of data we store is redundant. 
> This is because some of our aspects are very generic and intercept calls 
> of the same object (e.g. a PipelineComponent) several times, storing the 
> same information in several ProfilingData objects. I see no way to make 
> the aspects more specific, since we have no information which servlets, 
> sitemaps and pipeline components might be used and which methods are called.
> 
> Measuring the runtime of servlets, sitemaps and pipeline components is 
> now done at a method basis, which means that we have accurate data on 
> the runtime of the intercepted methods, but no data on the runtime 
> (lifetime) of a specific servlet or pipeline component.

this may sound a bit confusing to everyone not that much involved in 
this subproject.  But we are trying to get our code into trunk.  As soon 
as our initial patch [1] gets applied (Reinhard?) we'll provide a second 
patch with actual code so you guys have a better understanding of what 
we are talking about.  I hope some really interesting discussions can 
start from there. :)


Regards
Christoph


[1] https://issues.apache.org/jira/browse/COCOON3-36