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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
