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: Commit: New AltProfile package as reference implementation for an
Date Mon, 04 Mar 2002 15:11:39 GMT
>>I had the goal of coming up with a system which would make it easy to design
>>Profilability into any component (Note lower case ‘c’) without having \
>>to worry about performance.  This is the same thinking that has gone into many \
>>logging systems of late.  You add lots of debug logging to classes to make it \
>>easier to debug them at a later date.  This profiling system follows the same line
\
>>of thinking.
>>
> 
> Ok.  My approach was to send a startProfiling() message to the
> Profilables being monitored, and then send an endProfiling() message
> when it is all done.


My thinking was to try and make the Profiler fit into the existing frameworks as
much as possible.  The ProfilerManager is actually completely independant however
and actually quite flexible.  Assigning the ProfilerManager to the
ProfilerComponentManager is actually just one way to use it.

The ProfilerManager exposes the registerProfilable method which can be used to
register a Profilable directly at any time.  This is how the ComponentManager does
it.  May want to add other methods as well.


>>A component can be made profiler ready by implementing the Profilable interface.
>>This interface allows a component to expose a number of ProfilePoints as well as
>>tell the Profiler about any child Profilables.
>>
> 
> So far we are in sync.
> 
>>ProfilePoints are extremely light weight when they are not connected to the \
>>Profiler. So components can add ProfilePoints without having to worry about a \
>>performance hit when the Profiler is not in use.
>>
> 
> Yep.  Mine too.  The biggest difference I believe is the relationship of
> ProfileReport and Profiler.
> 
> 
>>This implementation has been divided into 4 packages:
>>
>>>1) excalibur.altprofile: Defines the base interfaces and classes that most \
>>>
>>components will directly make use of.
>>
> 
> Excellent.
> 
> 
> 
> 
>>2) excalibur.altprofile.component: Defines a new ProfilerComponentManager which \
>>extends the ExcaliburComponentManager and understands how to deal with Profilable
\
>>components.
>>
> 
> Kool.  I will most likely throw in something like this in the Container/
> ContainerManager stuff as well.  I will be refactoring a few things
> to make that code easier to use though...


It should be quite easy to hook up there are no dependancies on the Component
interface to get in your way.


>>3) excalibur.altprofile.profiler:  This package contains the guts of the system. 
\
>>It defines a ProfilerManager which is where all the work of profiling an Avalon
>>application is handled.
>>
> 
> Excellent.
> 
> 
> 
> 
>>4) excalibur.altprofile.profiler.gui: This package contains a reference \
>>implementation of a simple GUI which enables you to browse and view the profiler \
>>aware elements of an application.
>>
> 
> "We're not worthy! We're not worthy!"
> 
> Great work guys.  I mean it.
> 
>>The excalibur.altprofile.component package required that I make a couple changes to
>>the excalibur.component package to allow key classes to be extended.
>>
> 
> That's fine.
> 
>>So far, I have temporarily made the ResourceLimitingJdbcDataSource in the \
>>scratchpad Profilable to make it easy to test things out.  The ProfileManager also
\
>>includes default profile points for monitoring the JVM memory.
>>
> 
> Excellent.
> 
> 
>>Lets start out with a sample piece of code that will start up an application using
>>the ProfilerComponentManager and a Profiler GUI.  This code should be familiar to
>>anyone who has worked with the Excalibur ComponentManager:
>>
>>>------
>>>
>>DefaultContext context = new DefaultContext();
>>
>>>context.put("root", getServletContext().getRealPath("/"));
>>>
>>context.makeReadOnly();
>>
>>>DefaultConfigurationBuilder builder    = new DefaultConfigurationBuilder();
>>>
>>Configuration             systemConfig = builder.build(configStream);
>>
>>>DefaultLogKitManager logManager = new DefaultLogKitManager();
>>>
>>Logger lmLogger = Hierarchy.getDefaultHierarchy().getLoggerFor("log-mgr");
>>lmLogger.setPriority(Priority.getPriorityForName(systemConfig.getAttribute("log",
\
>>"INFO")));  logManager.setLogger(lmLogger);
>>logManager.configure(systemConfig.getChild("logkit"));
>>
>>>>// Set up the Profiler Manager
>>>>
>>DefaultProfilerManager profilerManager = new DefaultProfilerManager();
>>
>>>profilerManager.enableLogging(new LogKitLogger(logManager.getLogger("pm")));
>>>
>>profilerManager.configure(systemConfig.getChild("profiler"));
>>profilerManager.initialize();
>>
>>>// Set up the Role Manager
>>>
>>Configuration               roleConfig = builder.build(roleStream);
>>DefaultRoleManager          roles      = new DefaultRoleManager();
>>
>>>roles.setLogger(logManager.getLogger("rm"));
>>>
>>roles.configure(roleConfig);
>>
>>>>// Set up the Component Manager
>>>>
>>ProfilerComponentManager manager      = new ProfilerComponentManager();
>>
>>>manager.setLogger(logManager.getLogger("cm"));
>>>
>>manager.setLogKitManager(logManager);
>>manager.contextualize(context);
>>manager.setProfilerManager(profilerManager);
>>manager.setRoleManager(roles);
>>manager.configure(systemConfig.getChild("environment"));
>>manager.initialize();
>>
>>>// Set up the ProfilerFrame
>>>
>>ProfilerFrame profilerFrame = new ProfilerFrame( profilerManager, "Nikko System \
>>Profiler" );  profilerFrame.setVisible( true );
>>------
>>
>>>The differences are that this code creates a ProfilerManager and assigns it to
the
>>>
>>ProfilerComponentManager using the setProfilerManager() method.  The code then
>>continues to create a ProfilerFrame passing the ProfilerManager to the constructor.
>>The ProfilerFrame is not required by the Profiler.  It is just a default way to \
>>view the Profile data.
>>
> 
> By the way, It was suggested to me a while back that we should rename
> the Profiler stuff as Instrumentor, InstrumentationPoint, etc.  The
> reason being that we are not truly profiling, but instrumenting the
> system.  I would like to get this code up and running and final as
> soon as possible.  (I have a book to write, and this can really make
> an impact).


Should not be a problem.  The package needs to be renamed anyway.  I was actually
hoping to get this moved into jakarta-excalibur.jar fairly soon.  That would make it
possible to do lots of useful profiling of things that the ComponentManager is doing.
Such as lookups and releases of components and monitoring the pool sizes of poolable
components etc.


>>Without any other changes, your application should be able to be run using the \
>>above code to launch the application.  But at this point none of the Profilable \
>>components will be profiled because they have not been configured in the config \
>>file yet.
>>Components which implement Profilable are not added to the list of components to be
>>profiled by default.  To make them profilable, you must add a \
>>‘profilable’ attribute which gives them a profiler name.
>>
>>>Here is an example datasource configuration:
>>>
>>------
>><datasources>
>><jdbc name="asp-service" profilable="jdbc-asp-service">
>><pool-controller min="1" max="10"/>
>><auto-commit>true</auto-commit>
>><driver>org.postgresql.Driver</driver>
>><dburl>jdbc:postgresql://host/asp_service</dburl>
>><user>user</user>
>><password>pwd</password>
>></jdbc>
>></datasources>
>>------
>>
> 
> Ok.  Looks good.  We *may* want to make that alterable during run-time
> though.  For instance, the GUI may want to select specific Profilables
> that we are monitoring at any one time.


The profilable attribute gives the developer a way to completely components
from the profiler.

Components which are not configured in the profiler configuration can still
be profiled at run time.

The profiler configuration is just a way to assign human readable names to
components and to set up ProfileSamples which are running by default.  There
are some things that you want to have being profiled at all times so that you
can go back and look at them later.

It is currently possible to add Listeners at two different levels.

The first to is to directly add a CounterProfilePointListener or a
VisitorProfilePointListener to any profile point.  This method lets you write
any kind of report as you have access to all of the raw profile data coming
directly from the ProfilePoint.

The second method is to add a ProfileSampleListener to any of the ProfileSamples
assigned to a particular ProfilePoint.  This listener gets a filtered view of
the data.  If the listener is added to a MaximumValueProfileSample for example,
then the listener will be notified of new max values and when the sample period
has started.

Pretty much any kind of report should be possible by using one of the two
listener types.

The code is also 99% there to allow for ProfileSamples to be added at runtime as
well.  But my thinking in excluding that from the API is that if a user
application wishes to be managing their own report data, they can do that outside
of the ProfilerManager by listening for data send from the ProfilePoints.

<snip>



> I'm kind of luke-warm on this.  We should be able to determine the type
> of sample we are accepting automatically.  The reporting agent (whether
> gui or file) should be able to adjust the report to reflect the per
> second, per minute, per hour differences.  Especially since it is
> controlling the sampling frequency directly.


Did I answer this above?

> So far, kudos for the excellent work.  I will review the interfaces
> shortly, and let you know if I have any questions.


I'll look forward to hearing your thoughts.

Cheers,
Leif


--
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