Berin Loritsch wrote:
> > Basicly, the ProfilerManageable interface would have as its contract
> > that implementing classes
> > would need to be able to function whether the setProfilerManager method
> > was called or not.
> > But that the method would only be called during the object's
> > initialization phase.
>
> Let's keep it in scratchpad just a little while longer, there are a
> couple things to straighten out first. Once we have a GUI that can
> attach itself to an external JVM we can consider the move to the main
> package.
Sounds good. It looks like there are still several issues that need to
be worked out. First off is the name change though. Here is what I
was thinking:
packages:
.altprofile => .instrument
.altprofile.component => .instrument.component
.altprofile.profiler => .instrument.instrumentor
classes:
Profilable => Instrumentable
ProfilePoint => InstrumentPoint
ProfilerManager => InstrumentorManager
etc.
Thoughts / opinions before I start changing things name-wise? My
only issue is that the names are a bit long and might be annoying
to use after a while. But I would not want to use abreviations.
> The memory profilepoints should be default and part of the
> ProfileManager, and not ProfileableComponentManager. The PCM (when
> integrated with the ECM) should worry about the ComponentHandlers
> and other metadata that is specific to mananging components.
That is the way it is now, so I agree :-) While the PCM will be the
mail user of the PM, I really want the PM to be indepentant of it.
In addition to making it easy to be used elsewhere, it will also make
it easier to move over to using things like the ContainerManager.
> > lookup()
> > {
> > long start = System.currentTimeMillis();
> > // Do stuff
> > if ( m_lookupLengthProfilePoint.isActive() )
> > {
> > m_lookupLengthProfilePoint.setValue(
> > (int)(System.currentTimeMillis() - start) );
> > }
> > }
> >
> > This way will be a little faster when the profiler is disabled.
>
> True.
>
> I agree that this type of profiling is not entirely accurate, but this
> harness also allows us to inspect where time is being spent in a system.
> It does enable us to have a new implementation of JMeter that is more
> elegant.... I tried to talk to the JMeter folks about providing the GUI
> for our profiling package. It turns out that there are only a few folks
> working on that project, and they really don't have the resources to
> overhaul their code to support our profiling package :(.
>
> However, I will say that I *really* like the meters you have in
> altprofile! I discovered that if I click on the line, I can see the
> average mean of the profile samples superimposed on the actuals. That
> kicks butt!
Thanks. I was one of those things that I spent too much time on about a
year ago. Forgot to mention the average chart. I always use it without
thinking about it. :-)
Another way that the chart can be used is in generating Jpegs and such for
servlet responces etc. The code is not entirely in there, but it is easy
to make use of the paintComponent method passing it a Graphics object for
an image and the coponent will happily paint onto that so that. When we
get around to those kinds of clients, I can get the rest of that code in.
> BTW, would it be too difficult to add a Std. Deviation marking? Since
> Standard deviations are over a long aggregation of samples, it can be
> placed to the side of the graph. Usually the marks look like this:
>
> --+-- (Max)
> |
> * (Average Mean)
> |
> |
> |
> --+-- (Min)
>
> That way we can see that if results are not average, which side of the
> equation they lay on.
The problem is that this could not be done entirely in the chart. If it
was, then it would show the std of the data in the chart. Depending on
the ProfileSample. This might be the MaxValues per sample over time.
I think that is what is really needed is another ProfileSample type
called StandardDeviationValueProfileSample or something. It could track
three sets of data. The max, min and avg for each profile sample. Then
the LineChart could be modified to show all three sets of data maybe as
for each point???
Cheers,
Leif
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
