avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Mortenson <l...@silveregg.co.jp>
Subject Re: New AltProfile package
Date Thu, 07 Mar 2002 11:32:13 GMT
Ryan Shaw wrote:

>Hi Berin,
>Leif is not here yet so I'll try to answer your questions. This is
>totally his baby, though, so take my answers with a grain of salt.
>||| 1) Are you using the LogEnabled interface instead of the Loggable
>|||    interface?
>||| 2) Can you extend the example program to provide information about
>|||    the ProfilableComponentManager itself--with information about
>|||    lookups/second and releases/second?
>So the PCM already instrumented for memory so this would just be
>a matter of adding profile points for lookups/releases and adding
>them to the config.
The PCM is actually extremely light weight.  I am actually hoping to be 
able to get rid of it completly
by merging the changes into the ECM.  All it would require is added two 
more steps to the
component initialization phase.  One for Profilable and one for 
ProfilerManageable.  The guts of
the PCM are actually in the ECM.

If that change was made it would be very easy to add ProfilePoints into 
the ComponentHandlers
to be able to profile the lookups and releases on various components. 
 This would be very useful
as it would enable you to do a lot of profiling without having to add 
any Profilable code into the
individual components.  I would have to do lots of performance tests to 
make sure that this did
not do any harm, but the ProfilePoints are specifically designed to be 
VERY lightweight when a
ProfilerManager is not pressent.  Even with a ProfilerManager connected, 
they still have almost
no effect on performance until listeners are registered.

>||| 3) Is it possible to have the GUI and the ProfilerManager in separate
>|||    VMs?  It would be invaluable to determine the health of a servlet
>|||    like Cocoon, or blocks within Phoenix.
>Yeah, I really want this. Being a Unix guy, servers with attached
>GUIs make my skin crawl. But what would be the best way to detach
>the two? Would JMX be appropriate here?
I was actually already giving this some thought.  Is there something 
that can be done in parallel with
the work in Phoenix with JMX?  I am just getting my feet wet with that 
stuff.  Doing the necessary
abstractions to allow the ProfilerManager to be used via RMI is not very 

I would actually love to see Phoenix applications made for this.  One as 
a Swing GUI, and another
as a Servlet based tool.  Is there any other work going on GUI wise for 
Phoenix management.  I
have read talk of it. But...  No reason why this can't be the start.

>||| I liked the fact that the memory was well managed.  When I tested it
>||| with 100,000 doAction() events, I never exceeded 11M of max memory
>||| in the JVM.  That is a problem with JMeter's GUI event listeners.
>Leif is a memory ninja. :^)
>||| Another thing that I thought might be useful when you are testing
>||| systems with a profiler attached is to enable the ability to invoke
>||| the garbage collector with the GUI. If the GUI is attached to an
>||| external JVM, it should invoke the garbage collector in that VM.
>If the GUI were detached, what would be the purpose of invoking GC?
The GC would be invoked on the machine where the ProfilerManager was 
running.  Not on
the GUI machine.  I agree this would be a useful feature.

>||| Also, how exactly is the ProfilerManager listening for events?
The ProfilePoint has a setProfilePointProxy() method which is called by 
the ProfilerManager
when the ProfilePoint is registered by its Profilable component.  The 
ProfilePointProxy does
not contain any reference back to the ProfilePoint.  This removes the 
need for the ProfilerManager
to be in the loop for the destruction of ProfilePoints and their 
Profilable components.  The
ProfilePointProxy object reference is private to the ProfileProxy and 
this safe.

When an increment() or setValue() method is called on a ProfilePoint it 
checks to see whether
or not a Proxy has been set.  If so, the call is propagated to the 
Proxy.  The proxy then checks
whether or not any ProfilePointListeners have been registered.  If they 
have, then they are each
called, otherwise the call is thrown out.  Up to this point there has 
been no need to do any kind
of synchronization so this is VERY fast.

Now a ProfilePointListener can be anything.  But one implementation that 
is built into the altprofile
system is a ProfileSample object.  This object comes in a variety of 
flavors.  The
CounterProfileSample takes increment() events.  and the 
MaximumValueProfileSample, and MinimumValueProfileSamples each take 
setValue() events.
ProfileSamples are used in places where the profile history data needs 
to be maintained for future
use.  The ProfileSample takes care of breaking the individual events 
into sample periods which
together make up the history of the data collected from a ProfilePoint.

ProfileSamples can also have listeners registered  They are fired with 
information that has been
filtered through the sample.  For example if a MaximumValueSample 
receives the values 10,
100, 50, 60, 90, and 101 in that order within a single sample period. 
 The ProfileSampleListener
will only notified of the values 10, 100 and 101 because those are the 
only significant values.

Profilables, ProfilePoints, and ProfileSamples all have Descriptor 
classes which can be obtained
throught the ProfilerManager.  These Descriptors are used to give 
clients access to the Profiler
elements without giving them access to anything sensitive.

What would you think of going ahead and changing the package name to 
something more
permanent.  I would like to start seeing more people use this so that 
more of the usage issues
can be worked out.   You had mentioned that you would like to change the 
name from
Profiler to Instrumentor.  Shall I go ahead and do that by creating a 
new instrument package?

So far it is just a search and replace problem.  It will get more 
complicated later the more
people begin to play with it.


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message