Peter Donald wrote:
On Thu, 13 Dec 2001 13:47, Peter Royal wrote:
* Most things I know about would have components with multiple points. Is
this supported? Also sometimes points are aggregations of other points -
is this supported ? Something that may be useful would be to do something
like
//second parameter is the factor that the child point contribts to this
point myProfilePoint.getChildPoint( "some-string-designation", 0.01f );
In this way you could support hierarchies of points
hmm. can you give a more concrete example of where the aggregation would be
used?
hierarchy of methods on different components. ie Components C1, C2, C3, C4
and Methods M1, M2, M3 and M4 such that
C1.M1 calls C2.M2 and C3.M3. C2.M2 calls C4.M4
When profiling you want to know how much time in total was spent in M2 and
you also want to know how much time was spent in M4 (and thus how much was
spent solely in M2 without calling M4). Now instead of dealing with methods
this could be arbitrary resource usages.
I think I know where you are going. And I think we are talking about two
different types of profiling. For instance, the type of profiling that this
type of framework is best for would be tracking Pool MetaInformation, or if
DataSource Connection request/release was asymetrical (i.e. requested but
never closed...).
You are thinking more along the lines of a traditional profiler that handles
coverage reports and length of time for each method. That would never fit
this model of profiling, and I think it would be wrong to force it to happen.
There are different types of profiling needs, and this addresses specific
profiling needs for Avalon. There are other profiling tools that address
the type of needs you are describing here.
ie consider an EJB call or set of EJB calls - how much is spent in cache
layer, how much is spent in SQL layer, how much is spent walking through
stack and so forth.
Hmmm .. thats not making sense. I will try to explain better in another mail
from home.
The SEDA architecture never addressed that type of thinking. The average
time an event was spent in any one stage was extrapolated by averaging the
number of events a Stage processed with the time the sampling was being
performed.
* kinda related to above but is there a way for the container to
associate "context" information with a point. ie a Point may say it is
measuring variable X but the container may prepend this with
"myContainer.myComponentName."
Each ProfilePoint has a string name associated with it.
Right - but can the parent add to that name to give it context. So just say
we have two pools with identical properties except for their name (which is
managed by container). Is there a way for container to inject name into
profile point name.
Not at this time. Only the *direct* parent of the ProfilePoint can do that.
For instance, in the Pool example, ther can be as many as 5 or 6 ProfilePoints.
The Pool itself is able to add the type of object it is pooling, but it cannot
say if the Pool is a child of the JdbcDataSource or the PoolableComponentHolder.
However, in the case of the Pool, the classname should give enough context so
as to make it's context meaningful.
I would love to enable ExcaliburComponentManager to be Profilable. This way,
you can turn individual Components on and off for Profiling. In the
Configuration,
you would have a "magic" attribute that includes a ComponentHolder in the list
of profiled Components. For example:
<cocoon>
<datasources>
<jdbc profiling="true"/>
</datasources>
<classloader class="org.apache.cocoon......"/>
<monitor profiling="true"/>
</cocoon>
This would turn profiling on only for the "monitor" and "datasources". When the
Profiler was active, it would get the information only from those places.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
