You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/12/12 16:26:09 UTC
New Profiler hooks
I added a couple of interfaces in the Framework proposal directory that I think
could be good for debugging and performance monitoring a running system.
The new folder is ${framework}/src/proposal/profile
The two new interfaces are Profiler and Profilable. The concept (lifted from
SEDA) is that all profiling points are integers. For instance the types of
samples that are taken in a profiling tool are number calls on methods (integer
results determining coverage), number of milliseconds each method takes (integer
results determining hotspots), etc.
While it is impractical to determine the traditional Profiling points in a
running system without modifying the JVM or proxying _everything_, there are
a number of other profiling points that truly make sense. For instance,
Number of Active Threads in a Pool, Max Poolable items, Items processed
per sample, etc.
The concept is simple, and observes IoC in the following manner:
1) The Profiler is designed to live inside the Container. It is the Container's
job to register the Profilable elements with the Profiler. The Profiler is
in control of how often samples are taken, and how the information is serialized
to the destination file. It is the Container's responsibility to determine
where that file should be located.
2) The Profilable objects are designed to return very simple profiling points.
Possible Issues:
1) An Component may want to expose multiple profiling points. In this case, the
profiler would have to be passed to the object that registers specialized
Profilable objects. We would need a third interface to pass the Profiler
to the Components.
2) We might decide that it is a configurable item for the destination of the
profiling results, so the serialize(File) method might be removed.
3) We might not want to expose the isRunning() method to all the Components in
this case.
Purposeful Design Constraints
1) Profilable only provides a simple integer sample.
2) The existance of the Profiler must be optional.
3) The Profiler must be able to be added and removed from a system without
restarting it.
4) The Profiling should be done asynchronously so as not to interfere with
the critical path. That is why the Profiler polls the Profilable objects
instead of the Profilable objects posting changes.
Let me know what you think.
I believe that Profilable is a core concern area since we want to enable the
exposing of the internal state in a controlled manner. We want to be able
to profile object state so we know where excessive work is being performed.
I also think that a useful Profiler would be better created in Excalibur,
so there is a dicotomy. The interface should be in Framework so that people
know how to design their containers to work with a Profiler.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Peter Royal <pr...@managingpartners.com>.
On Wednesday 12 December 2001 05:11 pm, you wrote:
> I really want to keep the Profiler as isolated from the Profilable class as
> possible. In order for it to be effective, the Profilable class must be
> able to function without the existance of the Profiler, but expose the
> profiling information when needed.
Agree. How about also providing a getName() on Profilable, thus eliminating
the need to make ProfilePoint.getName() be something like "Pool: Max Size".
That way a subclass of an excalibur pool implementation could set the
Profilable.getName() to be something (or maybe use Configuration.getName() as
a default). If you have multiple pools, having all the profile points named
"Pool: Max Size" could be confusing as to which pool it came from.
> I incorporated this idea, but renamed it to:
>
> startProfiling();
> and
> stopProfiling();
>
> This way the profiling process can be run multiple times during the life of
> a system--and no bad side-effects should happen. Profiling should only
> occur on active components/objects and not on ones that are initializing...
kewl. good point :)
> BTW, what is the thought on the "serialize(File)" method?
>
> The more I look at that, the less I like it. The question is, should this
> be a method directly set by a container, or should this be a configurable
> item?
It doesn't give me a warm fuzzy. I think your comment helped on that, as why
make a Profiler subclass just for a different output format? Also I'm not
sure if Configuration objects are the right output for this either.
My gut feeling is to expose two methods,
String[] getProfilePoints()
int[][] getProfileData()
but I know that's not optimal either.
Perhaps another class such as a ProfileSerializer, so you have
Profiler.serialize( ProfileSerializer serializer );
and
interface ProfileSerializer
{
void setColumns( String[] columns );
void setPoints ( int timestamp, int[] values );
}
or such.
And we can have concrete implementations of ProfileSerializer such as
CSVProfileSerializer, SAXProfileSerializer, JdbcProfileSerializer, etc.
Just thinking outloud. I may have had too much ioc/soc punch today :)
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Peter Donald <pe...@apache.org>.
On Thu, 13 Dec 2001 09:36, Paulo Gaspar wrote:
> Is it an option to use AspectJ for this kind of thing?
>
> If you do not know it take a look at:
> http://aspectj.org/
>
> and especially at the slides downloadable from:
> http://aspectj.org/doc/papersAndSlides
>
> It has a Mozilla license and, anyway, it is a tool and
> not a library.
AspectJ is fairly kool tool and about a year or two ago when me and Berin
first joined Avalon we talked about integrating it fairly strongly (Also
talked about integrating with IContract). Neither of those tools were
completely mature at that point but they were still very useful and mature
enough.
However the main reason we shied away from it was that it mean writing
non-standard java code and using very specific tools. Avalon already requires
a largish investement before you see any returns and integrating with Avalon
would have skyrocketed if we required users to also use these tools.
Thus why Avalon/Framework is largley a infrastructure for implementing
certain aspects programatically.
--
Cheers,
Pete
*-----------------------------------------------------------------------*
PROGRAM: n. a magic spell cast over a computer allowing it to turn
one's input into error messages. v.t. to engage in a pastime similar
to banging one's head against a wall, but with fewer opportunities for
reward.
*-----------------------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: New Profiler hooks
Posted by Paulo Gaspar <pa...@krankikom.de>.
Is it an option to use AspectJ for this kind of thing?
If you do not know it take a look at:
http://aspectj.org/
and especially at the slides downloadable from:
http://aspectj.org/doc/papersAndSlides
It has a Mozilla license and, anyway, it is a tool and
not a library.
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> I like your approach better, as the logic for the ProfilePoint's can be
> reused.
>
> How about renaming the current Profilable to be ProfilePoint, and then the
> ProfileEnabled in your ProfiledPool above can be Profilable?
>
> So you have a class that is Profilable, which has an
> void enableProfiling( Profiler profiler )
> method which registers ProfilePoints with the Profiler?
I incorporated your suggestions, with some modifications. I think that this
version is better than both my original proposal and some of the changes you
proposed.
I really want to keep the Profiler as isolated from the Profilable class as
possible. In order for it to be effective, the Profilable class must be able
to function without the existance of the Profiler, but expose the profiling
information when needed.
>>Using this approach, the Profiler implementation is easier at the cost of
>>extra objects in the system. Of course, the pool can be optimized with the
>>isRunning() method.
>>
>
> As far as the m_profiler.isRunning(), how about making Profilable have
> another method
> void disableProfiling()
I incorporated this idea, but renamed it to:
startProfiling();
and
stopProfiling();
This way the profiling process can be run multiple times during the life of
a system--and no bad side-effects should happen. Profiling should only
occur on active components/objects and not on ones that are initializing...
> So rather than calling m_profiler.isRunning() (which would give an NPE in
> your example if enableProfiling() hadn't been called :)
>
> a Profileable object would want to keep an internal boolean indicating if
> profiling had been enabled, and only update the ProfilePoint's accordingly
> then.
Great idea!
> Although that is neater, I think the slightly-more-complex examples above
> will be more useful in the end due to the reusability of the ProfilePoint's.
> -pete
Cool, then that is what is in the proposal (along with the renamed but
similarly functioning sample ProfilePoints). The only thing left is to provide
a sample....
BTW, what is the thought on the "serialize(File)" method?
The more I look at that, the less I like it. The question is, should this be
a method directly set by a container, or should this be a configurable item?
That is my point of indecision. It would be good to get more feedback on this
though.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Peter Royal <pr...@managingpartners.com>.
On Wednesday 12 December 2001 11:17 am, you wrote:
> Keep in mind the other option here:
>
> For a pool, the current size and max grown are the useful profiling points
> as the defined min and max are directly set in configuration. Therefore,
> what I was thinking is this:
Thanks for the more detail explanantion :)
> class ProfiledPool implements Pool, ProfileEnabled
> {
> ProcessedPerPeriodProfilePoint m_gets;
> ProcessedPerPeriodProfilePoint m_puts;
> ItemCountProfilePoint m_activeObjects;
> ItemCountProfilePoint m_reserveObjects;
> MaxProfilePoint m_maxRequested;
> Profiler m_profiler;
> List m_active;
> List m_reserve;
I like your approach better, as the logic for the ProfilePoint's can be
reused.
How about renaming the current Profilable to be ProfilePoint, and then the
ProfileEnabled in your ProfiledPool above can be Profilable?
So you have a class that is Profilable, which has an
void enableProfiling( Profiler profiler )
method which registers ProfilePoints with the Profiler?
> Using this approach, the Profiler implementation is easier at the cost of
> extra objects in the system. Of course, the pool can be optimized with the
> isRunning() method.
As far as the m_profiler.isRunning(), how about making Profilable have
another method
void disableProfiling()
So rather than calling m_profiler.isRunning() (which would give an NPE in
your example if enableProfiling() hadn't been called :)
a Profileable object would want to keep an internal boolean indicating if
profiling had been enabled, and only update the ProfilePoint's accordingly
then.
> Then again, it may be simply neater to export multiple sample points:
>
> String[] getSampleNames();
> int[] getSamples();
>
> Which is not *that* much more difficult to implement in the profiler.
> The question arrizes of how to determine whether we are profiling or
> not.
Although that is neater, I think the slightly-more-complex examples above
will be more useful in the end due to the reusability of the ProfilePoint's.
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Wednesday 12 December 2001 10:26 am, you wrote:
>
>>Purposeful Design Constraints
>>
>>1) Profilable only provides a simple integer sample.
>>
>
> Why is that a purposeful constraint? That constraint is directly responsible
> for your issue #1, multiple points per component. I think issue #1 is huge
> because for a pool you many want to know current size, defined max & min, max
> it has ever grown to, etc. I think multiple points/component would be the
> norm, rather than the excepetion.
>
> How about changing Profilable to
>
> interface Profilable
> {
> /**
> * A list of the sample points that this component exposes.
> */
> String[] getSamplePoints();
>
> /**
> * Obtain the sample. All samples are an integer, so the profiled objects
> * must measure quantity (numbers of items), rate (items/period), time in
> * milliseconds, etc.
> */
> int getSample(String point);
> }
>
> Otherwise I think the proposal looks good! :)
> -pete
Keep in mind the other option here:
For a pool, the current size and max grown are the useful profiling points
as the defined min and max are directly set in configuration. Therefore, what
I was thinking is this:
A pool defines a series of objects like this:
class MaxProfilePoint implements Profilable
{
int m_max = 0;
void setActive( int currentActive )
{
if ( m_max < currentActive )
{
m_max = currentActive;
}
}
int getSample()
{
return m_max;
}
}
class ItemCountProfilePoint implements Profilable
{
int m_current = 0;
void setActive( int currentActive )
{
m_current = currentActive;
}
int getSample()
{
return m_current;
}
}
class ProcessedPerPeriodProfilePoint implements Profilable
{
int m_current = 0;
void increment()
{
m_current++;
}
int getSample()
{
return m_current;
m_current = 0;
}
}
If the profiler was passed to the Pool implementation, then the
specific profile objects would be passed to the Profiler. Kind
of like this:
class ProfiledPool implements Pool, ProfileEnabled
{
ProcessedPerPeriodProfilePoint m_gets;
ProcessedPerPeriodProfilePoint m_puts;
ItemCountProfilePoint m_activeObjects;
ItemCountProfilePoint m_reserveObjects;
MaxProfilePoint m_maxRequested;
Profiler m_profiler;
List m_active;
List m_reserve;
Poolable get()
{
if (m_profiler.isRunning())
{
m_gets.increment();
}
m_active.add(m_reserve.remove(0));
if (m_profiler.isRunning())
{
m_maxRequested.setActive(m_active.size());
m_activeObjects.setActive(m_active.size());
m_reserveObjects;.setActive(m_reserve.size());
}
}
void put( Poolable obj )
{
if (m_profiler.isRunning())
{
m_puts.increment();
}
m_active.remove( obj );
m_reserve.add( obj );
if (m_profiler.isRunning())
{
m_activeObjects.setActive(m_active.size());
m_reserveObjects;.setActive(m_reserve.size());
}
}
void enableProfiling( Profiler profiler )
{
profiler.add( "Pool: number of gets/sample", m_gets );
profiler.add( "Pool: number of puts/sample", m_puts );
profiler.add( "Pool: max concurrent active objects", m_maxRequested);
profiler.add( "Pool: current number of reserve objects", m_reserveObjects);
profiler.add( "Pool: current number of active objects", m_activeObjects);
m_profiler = profiler;
}
}
Using this approach, the Profiler implementation is easier at the cost of
extra objects in the system. Of course, the pool can be optimized with the
isRunning() method.
Then again, it may be simply neater to export multiple sample points:
String[] getSampleNames();
int[] getSamples();
Which is not *that* much more difficult to implement in the profiler.
The question arrizes of how to determine whether we are profiling or
not.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Peter Royal <pr...@managingpartners.com>.
On Wednesday 12 December 2001 10:26 am, you wrote:
> Purposeful Design Constraints
>
> 1) Profilable only provides a simple integer sample.
Why is that a purposeful constraint? That constraint is directly responsible
for your issue #1, multiple points per component. I think issue #1 is huge
because for a pool you many want to know current size, defined max & min, max
it has ever grown to, etc. I think multiple points/component would be the
norm, rather than the excepetion.
How about changing Profilable to
interface Profilable
{
/**
* A list of the sample points that this component exposes.
*/
String[] getSamplePoints();
/**
* Obtain the sample. All samples are an integer, so the profiled objects
* must measure quantity (numbers of items), rate (items/period), time in
* milliseconds, etc.
*/
int getSample(String point);
}
Otherwise I think the proposal looks good! :)
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Peter Donald <pe...@apache.org>.
Haven't looked at it closely yet but it sounds good so far. However I don't
think it has anything to do with lifecycle management and thus should
probably go into excalibur (much like Recyclable/Poolable is in
excalibur).
Just a few questions.
* Does it allow for push and pull?
ie can the component to push the profile data regardless of whether anyone is
listeneing. Can the Profiler actually pull a sample out any time it wants?
* 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
* 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."
On Thu, 13 Dec 2001 02:26, Berin Loritsch wrote:
> I added a couple of interfaces in the Framework proposal directory that I
> think could be good for debugging and performance monitoring a running
> system.
>
> The new folder is ${framework}/src/proposal/profile
>
> The two new interfaces are Profiler and Profilable. The concept (lifted
> from SEDA) is that all profiling points are integers. For instance the
> types of samples that are taken in a profiling tool are number calls on
> methods (integer results determining coverage), number of milliseconds each
> method takes (integer results determining hotspots), etc.
>
> While it is impractical to determine the traditional Profiling points in a
> running system without modifying the JVM or proxying _everything_, there
> are a number of other profiling points that truly make sense. For
> instance, Number of Active Threads in a Pool, Max Poolable items, Items
> processed per sample, etc.
>
> The concept is simple, and observes IoC in the following manner:
>
> 1) The Profiler is designed to live inside the Container. It is the
> Container's job to register the Profilable elements with the Profiler. The
> Profiler is in control of how often samples are taken, and how the
> information is serialized to the destination file. It is the Container's
> responsibility to determine where that file should be located.
>
> 2) The Profilable objects are designed to return very simple profiling
> points.
>
>
> Possible Issues:
>
> 1) An Component may want to expose multiple profiling points. In this
> case, the profiler would have to be passed to the object that registers
> specialized Profilable objects. We would need a third interface to pass
> the Profiler to the Components.
>
> 2) We might decide that it is a configurable item for the destination of
> the profiling results, so the serialize(File) method might be removed.
>
> 3) We might not want to expose the isRunning() method to all the Components
> in this case.
>
> Purposeful Design Constraints
>
> 1) Profilable only provides a simple integer sample.
>
> 2) The existance of the Profiler must be optional.
>
> 3) The Profiler must be able to be added and removed from a system without
> restarting it.
>
> 4) The Profiling should be done asynchronously so as not to interfere with
> the critical path. That is why the Profiler polls the Profilable
> objects instead of the Profilable objects posting changes.
>
> Let me know what you think.
>
> I believe that Profilable is a core concern area since we want to enable
> the exposing of the internal state in a controlled manner. We want to be
> able to profile object state so we know where excessive work is being
> performed. I also think that a useful Profiler would be better created in
> Excalibur, so there is a dicotomy. The interface should be in Framework so
> that people know how to design their containers to work with a Profiler.
--
Cheers,
Pete
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> Haven't looked at it closely yet but it sounds good so far. However I don't
> think it has anything to do with lifecycle management and thus should
> probably go into excalibur (much like Recyclable/Poolable is in
> excalibur).
I might be inclined to agree with you--especially concidering to the point that
it is growing.
> Just a few questions.
>
> * Does it allow for push and pull?
> ie can the component to push the profile data regardless of whether anyone is
> listeneing. Can the Profiler actually pull a sample out any time it wants?
It is Pull only. The idea is to minimize the awareness of the Component being
profiled so that it _only_ provides the hooks so the Profiler can get the
information needed.
Also, as a courtesy, the Profiler tells the Component when it is running, so
the Component does not _have_ to track information when it is not necessary
(thus an optimization technique on par with the LogKit.is[Priority]Enabled).
> * 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
That's the same thing Pete Royal came up with. The SEDA architecture was merely
measuring queue size and threadpool size. This is too limited for our needs.
> //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
The current version of Profilable has one method to getProfilePoints. The
ProfilePoints used in this system has an associated name. If a Profilable
happens to be a container, it can also go through it's children and gather
their profilable points.
> * 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."
Currently, not directly. A pool can easily look at it's ObjectFactory to
get the Class name of the type of object it is pooling and use that in the
ProfilePoint's name. Kind of like this:
"{classname} Pool: Max Size"
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Berin Loritsch <bl...@apache.org>.
Chad Stansbury wrote:
> I think it is important to distinguish between profiling and
> *instrumenting*. The discussion being held up to this point is really about
> instrumenting the code - so the Profilable interface is, IMO, a bit of a
> misnomer. I think it should be renamed Instrumentable.
>
> Thoughts?
It makes sense. The name Profiler, et. al. was derived from the SEDA architecture,
and the mistaken nomencature was passed on. Once we get to an arrangement for the
architecture that we like, we can start changing the names.
But you are correct, this is *instrumenting* the code.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Chad Stansbury <st...@earthlink.net>.
I think it is important to distinguish between profiling and
*instrumenting*. The discussion being held up to this point is really about
instrumenting the code - so the Profilable interface is, IMO, a bit of a
misnomer. I think it should be renamed Instrumentable.
Thoughts?
----- Original Message -----
From: "Peter Donald" <pe...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Thursday, December 13, 2001 1:00 PM
Subject: Re: New Profiler hooks
> On Fri, 14 Dec 2001 00:53, Berin Loritsch wrote:
> > > 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.
>
> Hmmm ... well I wasn't actually thinking about it in that way but I guess
the
> example came across that way. Hmmm. I still think hierarchial points would
be
> useful though
>
> --
> Cheers,
>
> Pete
>
> ---------------------------------------------------
> "Wise men don't need advice. Fools don't take it."
> -Benjamin Franklin
> ---------------------------------------------------
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 14 Dec 2001 00:53, Berin Loritsch wrote:
>
>>>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.
>>
>
> Hmmm ... well I wasn't actually thinking about it in that way but I guess the
> example came across that way. Hmmm. I still think hierarchial points would be
> useful though
Check my response in the other email.
*your email may be slow....*
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Peter Donald <pe...@apache.org>.
On Fri, 14 Dec 2001 00:53, Berin Loritsch wrote:
> > 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.
Hmmm ... well I wasn't actually thinking about it in that way but I guess the
example came across that way. Hmmm. I still think hierarchial points would be
useful though
--
Cheers,
Pete
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 14 Dec 2001 08:08, Berin Loritsch wrote:
>
>>The problem arrizes with how do we determine what the parent ProfilePoint
>>is?
>>
>
> Same way as Logger, ComponentManager, Context, etc does.
Yes, but think Profilable.
The problem arrizes when there is no artifact passed in.
>>It does not make sense to have a Pool's max active ProfilePoint be the
>>parent of an ObjectFactory's number of created instances ProfilePoint.
>>They represent something completely unique.
>>
>
> eh? Could you rephrase ? ;)
For instance, ProfilePoints are unique sample types that are used by the
Profiler. It does not make sense for two dissasociated ProfilePoints to
be forced into a heirarchy when they are inherently flat.
>>If this is going to scale, we *have* to make it happen at the Profilable
>>level. Remember, this is IoC, so a child Profilable is not going to have
>>access to the Parent's ProfilePoints at all.
>>
>
> and a child Profilable should not directly create its top ProfilePoint, IOC
> and all
Think of it in this manner (it doesn't *have* to be this hard you know):
Any Profilable that wants to publish it's ProfilePoints may do so. The
Profilable object assigns names to all of it's ProfilePoints. In heirarchical
situations, the Parent Profilable not only publishes its ProfilePoints, but
also those of it's children. It also propogates the startProfiling() and
stopProfiling() methods to its children when they are called.
Seeing how the parent Profilable does not directly set the ProfilePoints'
names unless it originated from the Profilable, there must be a different
mechanism to propogate hierarchical names to the child Profilables.
>>>and the name would be set via
>>>
>>>parent.getName() + myName
>>>
>>>however the method getName() would be protected, package or private
>>>access (depending on what we could get away with) and done in the case
>>>class.
>>>
>>I don't like this, as it is Subversion of Control. A child should not have
>>a direct reference to it's parent. The name has to come from being
>>assigned, or we trust the Component to use proper "divination" to generate
>>a meaningful name.
>>
>
> why can't it operate like all our other hierarchial aspects?
Our other hierarchical aspects have artifacts that are passed down to the
children, as opposed to passed up to the Profiler. We are in essence
exposing the inner workings of an object in a controlled manner.
The only other way I can think of providing this functionality would be
to have YAI (Yet Another Interface) to mark a ProfilableContainer. In
this case, the ProfilableContainer can expose the Profilables directly.
The ProfilableContainer would have a getName(), the Profilable would have
a getName(), and the ProfilePoints() would have a getName().
The last possible way is to have a getChildProfilables() in the Profilable
interface with the Profilable having a getName().
The Profiler would then have to assemble the final names from the heirarchical
getNames(). Going back to the ECM example, the ECM would be Profilable,
Profilable[] group = ecm.getChildProfilables();
This can of course return an empty array.
This would produce a hierarchy of grouped names, and would require us to
rethink the actual ProfileReport's interface so as to maintain those groups
in the reports.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Peter Donald <pe...@apache.org>.
On Fri, 14 Dec 2001 08:08, Berin Loritsch wrote:
> The problem arrizes with how do we determine what the parent ProfilePoint
> is?
Same way as Logger, ComponentManager, Context, etc does.
> It does not make sense to have a Pool's max active ProfilePoint be the
> parent of an ObjectFactory's number of created instances ProfilePoint.
> They represent something completely unique.
eh? Could you rephrase ? ;)
> If this is going to scale, we *have* to make it happen at the Profilable
> level. Remember, this is IoC, so a child Profilable is not going to have
> access to the Parent's ProfilePoints at all.
and a child Profilable should not directly create its top ProfilePoint, IOC
and all
> > and the name would be set via
> >
> > parent.getName() + myName
> >
> > however the method getName() would be protected, package or private
> > access (depending on what we could get away with) and done in the case
> > class.
>
> I don't like this, as it is Subversion of Control. A child should not have
> a direct reference to it's parent. The name has to come from being
> assigned, or we trust the Component to use proper "divination" to generate
> a meaningful name.
why can't it operate like all our other hierarchial aspects?
--
Cheers,
Pete
-----------------------------------------------------------
If your life passes before your eyes when you die,
does that include the part where your life passes before
your eyes?
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 14 Dec 2001 07:06, Berin Loritsch wrote:
>
>>So if the "Profilable" interface was changed to add the setName(), we could
>>implement something like this:
>>
>>interface Profilable {
>> void setName( String name );
>> // ..... skip other already declared methods .....
>>}
>>
> ...snip...
>
>>What are your feelings on the subject?
>>
>
> I really dislike any notion of a public setName() method. Perhaps it would be
> better to allow points to create their own children. If that is not viable
> for whatever reason then you could make constructors look like
>
>
> class MyPoint
> {
> MyPoint( Point parent, String myName )
> {
> super( parent, myName );
> }
> }
The problem arrizes with how do we determine what the parent ProfilePoint is?
It does not make sense to have a Pool's max active ProfilePoint be the parent
of an ObjectFactory's number of created instances ProfilePoint. They represent
something completely unique.
If this is going to scale, we *have* to make it happen at the Profilable level.
Remember, this is IoC, so a child Profilable is not going to have access to the
Parent's ProfilePoints at all.
We have to come up with a solution where the name is given by the parent to the
child, like everything else.
> and the name would be set via
>
> parent.getName() + myName
>
> however the method getName() would be protected, package or private access
> (depending on what we could get away with) and done in the case class.
I don't like this, as it is Subversion of Control. A child should not have
a direct reference to it's parent. The name has to come from being assigned,
or we trust the Component to use proper "divination" to generate a meaningful
name.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Peter Donald <pe...@apache.org>.
On Fri, 14 Dec 2001 07:06, Berin Loritsch wrote:
> So if the "Profilable" interface was changed to add the setName(), we could
> implement something like this:
>
> interface Profilable {
> void setName( String name );
> // ..... skip other already declared methods .....
> }
...snip...
>
> What are your feelings on the subject?
I really dislike any notion of a public setName() method. Perhaps it would be
better to allow points to create their own children. If that is not viable
for whatever reason then you could make constructors look like
class MyPoint
{
MyPoint( Point parent, String myName )
{
super( parent, myName );
}
}
and the name would be set via
parent.getName() + myName
however the method getName() would be protected, package or private access
(depending on what we could get away with) and done in the case class.
--
Cheers,
Pete
*------------------------------------------------------*
| Hlade's Law: If you have a difficult task, give it |
| to a lazy person -- they will find an easier |
| way to do it. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Berin Loritsch <bl...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Thu, 13 Dec 2001 13:47, Peter Royal wrote:
>
>>It looks like you read over it before Berin incorporated changes from our
>>exchange... might want to go back and look again :)
>>>* 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.
Ok. Pete Royal (man, two Peters :) had a proposal that the Profilable
would also have a name. In essence, this would allow a grouping to happen.
Let's take the ExcaliburComponentManager as an example. It is a Container
that has several Components, that can also be containers. If the Profilable
had a getName() parameter, that name would apply to all of it's ProfilePoints
as a grouping. So for instance, going to the PoolableComponentHolder implementation,
it would have all the ProfilePoints for the ObjectFactory and the Pool.
It would supply a name for that particular group of ProfilePoints.
The problem with this (other than the fact that ProfilePoints already have
a name associated with them), is that when a Profilable object has a group
of Profilable objects. In this case, the profiling tool is opaque. You cannot
go beyond one level.
The question comes then should all Components have a name set by the Container?
If so, then the Component interface should have a setName() interface.
If not, then the Profilable interface should be able to have a setName() method.
I lean toward the second, although you are at the mercy of the Component/Object
being profiled to respect that name and use it in it's ProfilePoints. This is
also important to track instance specific data. For instance, if we discovered
that the ECM was generating more than one JdbcConnection object for a connection
name, then we would have to track all the activities of each of the instances.
So if the "Profilable" interface was changed to add the setName(), we could
implement something like this:
interface Profilable {
void setName( String name );
// ..... skip other already declared methods .....
}
The ComponentManager when created will be given a name (setName):
ecm.setName("Root");
It would then go through all of it's ComponentHolders (if they implement Profilable),
and call setName() for them:
Iterator i = m_components.keySet().iterator();
while (i.hasNext())
{
String name = (String) i.next();
Profilable holder = (Profilable) m_components.get( name );
holder.setName( m_name + "." + name);
}
And in turn, the ComponentHolders (assuming they are made Profilable) will create the
actual ProfilePoints like this:
point = new CurrentValueProfilePoint( m_name + ".Pool: Current number of active components" );
It is easy to enforce this on the small scale, but what if the setName() method is never called?
It is not an official lifecycle service, and is likely to be missed. Another option is to allow
Components to be instantiated with a single argument constructor (a String for the name). This
does make the ObjectFactory more complicated, but it allows the process to happen wether there
is a name provided or not.
Of course we could also specify that the semantics of the setName() method *if* called serves
only to override the name attributed to a Profilable object.
What are your feelings on the subject?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Peter Donald <pe...@apache.org>.
On Thu, 13 Dec 2001 13:47, Peter Royal wrote:
> It looks like you read over it before Berin incorporated changes from our
> exchange... might want to go back and look again :)
yep - no enough cycles in the day to keep up it seems ;)
> > * 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.
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.
> > * 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.
--
Cheers,
Pete
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Ulrich Mayring <ul...@denic.de>.
Leif Mortenson wrote:
>
> Would profiling be a feature that is either on or off, or would it
> support something annalogous to log levels?
>
> Our current product has several runtime meters where we keep track of
> things like the number of queries to our server per second, the maximum
> and average query times, maximum connection counts, memory usage, etc.
We have something like that as well. I'm not familiar with the details,
but it involves a block listener and an RMI server. Basically, for the
block coder it means he just has to implement an interface and add a
couple of methods to his block and that's it. He's even free to add some
methods, but not others, as our external runtime statistics gatherer
will find out by itself if they exist and then proceed to call them in
intervals or not call them.
Again, I'm not familiar with our system, but I believe it strictly
observes the "Avalon way" and IoC. If there is interest I can ask my
colleague to describe the system in detail.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Leif Mortenson <le...@silveregg.co.jp>.
Would profiling be a feature that is either on or off, or would it
support something annalogous to log levels?
Our current product has several runtime meters where we keep track of
things like the number of queries to our server per second, the maximum
and average query times, maximum connection counts, memory usage, etc.
Then we enable the user to see graphs of this information with a 10
minute window at 1 second intervals, a 1 day window at 10 minute
intervals, or a 30 day window at 1 hour intervals. (See image)
The graphs would obviously just be a consumer of the profiled data, but
is allowing collection of this kind of run-time performance data
something that you had in mind?
The meter that we use to collect the data behind these graphs takes an
interval in seconds. Then it can opperate in one of 3 modes. 1) is to
record the total count over an interval. 2) is to record the average
value of points capured during a specific interval, and 3) is to record
the maximum value of the points capured during an interval.
Leif
Re: New Profiler hooks
Posted by Peter Royal <pr...@managingpartners.com>.
It looks like you read over it before Berin incorporated changes from our
exchange... might want to go back and look again :)
On Wednesday 12 December 2001 08:55 pm, you wrote:
> * Does it allow for push and pull?
> ie can the component to push the profile data regardless of whether anyone
> is listeneing. Can the Profiler actually pull a sample out any time it
> wants?
>From the interfaces described, yes to both of those. A component can keep
updating ProfilePoints regardless of whether or not a Profiler is actually
listening.
> * 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? But for the first question, yes. A component can have multiple points.
> * 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.
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Profiler hooks
Posted by Peter Donald <pe...@apache.org>.
Haven't looked at it closely yet but it sounds good so far. However I don't
think it has anything to do with lifecycle management and thus should
probably go into excalibur (much like Recyclable/Poolable is in
excalibur).
Just a few questions.
* Does it allow for push and pull?
ie can the component to push the profile data regardless of whether anyone is
listeneing. Can the Profiler actually pull a sample out any time it wants?
* 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
* 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."
On Thu, 13 Dec 2001 02:26, Berin Loritsch wrote:
> I added a couple of interfaces in the Framework proposal directory that I
> think could be good for debugging and performance monitoring a running
> system.
>
> The new folder is ${framework}/src/proposal/profile
>
> The two new interfaces are Profiler and Profilable. The concept (lifted
> from SEDA) is that all profiling points are integers. For instance the
> types of samples that are taken in a profiling tool are number calls on
> methods (integer results determining coverage), number of milliseconds each
> method takes (integer results determining hotspots), etc.
>
> While it is impractical to determine the traditional Profiling points in a
> running system without modifying the JVM or proxying _everything_, there
> are a number of other profiling points that truly make sense. For
> instance, Number of Active Threads in a Pool, Max Poolable items, Items
> processed per sample, etc.
>
> The concept is simple, and observes IoC in the following manner:
>
> 1) The Profiler is designed to live inside the Container. It is the
> Container's job to register the Profilable elements with the Profiler. The
> Profiler is in control of how often samples are taken, and how the
> information is serialized to the destination file. It is the Container's
> responsibility to determine where that file should be located.
>
> 2) The Profilable objects are designed to return very simple profiling
> points.
>
>
> Possible Issues:
>
> 1) An Component may want to expose multiple profiling points. In this
> case, the profiler would have to be passed to the object that registers
> specialized Profilable objects. We would need a third interface to pass
> the Profiler to the Components.
>
> 2) We might decide that it is a configurable item for the destination of
> the profiling results, so the serialize(File) method might be removed.
>
> 3) We might not want to expose the isRunning() method to all the Components
> in this case.
>
> Purposeful Design Constraints
>
> 1) Profilable only provides a simple integer sample.
>
> 2) The existance of the Profiler must be optional.
>
> 3) The Profiler must be able to be added and removed from a system without
> restarting it.
>
> 4) The Profiling should be done asynchronously so as not to interfere with
> the critical path. That is why the Profiler polls the Profilable
> objects instead of the Profilable objects posting changes.
>
> Let me know what you think.
>
> I believe that Profilable is a core concern area since we want to enable
> the exposing of the internal state in a controlled manner. We want to be
> able to profile object state so we know where excessive work is being
> performed. I also think that a useful Profiler would be better created in
> Excalibur, so there is a dicotomy. The interface should be in Framework so
> that people know how to design their containers to work with a Profiler.
--
Cheers,
Pete
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>