avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject New Profiler hooks
Date Wed, 12 Dec 2001 15:26:09 GMT
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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message