Leif Mortenson wrote:
> Ryan Shaw wrote:
>
>> Hi Berin,
>>
>> ||| 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
> difficult.
Check out AltRMI, it is a quicker implementation, and is an Apache
project (in Jakarta Commons). We are using it in Avalon Apps.
>> ||| 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.
Precisely.
> 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?
Yes. I would also go ahead and remove the profile package and
altprofile package, so we can focus all effort on the instrument
package. This package, IMO, makes Excalibur suddenly really
popular. If we can get this finalized by the time I get to covering
Excalibur in my book (sometime after May) I can cover it.
> So far it is just a search and replace problem. It will get more
> complicated later the more
> people begin to play with it.
Exactly.
The reason I wanted the PCM to record lookup/release cycles is because
I want to run a modified version of the ContainerProfile class to see
where the slowdown is. I want to instrument ContainerManager as well
so that we can see what is going on. Right now I am seeing 113:1
performance difference. If I extend the default timeout for the Command
Manager, the gap narrows. However, I do not see appreciable activity
on the CPU to check events every 1/10 of a second--which is what gives
the CommandManager the ability to rock.
How difficult is it to measure average timing of a method with the
altprofile package?
lookup()
{
m_lookupLengthProfilePoint.start();
// .... Do stuff
m_lookupLengthProfilePoint.stop();
}
lookup()
{
long start = System.currentTimeMillis();
// .... Do stuff
m_lookupLengthProfilePoint.setValue( System.currentTimeMillis() -
start );
}
The latter would probably be more correct....
--
"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]>
