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: New AltProfile package
Date Fri, 08 Mar 2002 05:41:08 GMT
Marcus Crafter wrote:

>>>Profile point proxies let you register listener classes for
>>>	updates from the profile points themselves. The listeners can be
>>>	implementors of a lower level ProfilePointListener class, or
>>>	high level Sample classes.
>>Almost.  The ProfilePointListener is not meant to be implemented directly.
>>It is just the super class of the CounterProfilePointListener and
>>ValueProfilePointListener interfaces.  Those two types of listeners can be
>>regestered with a ProfilePoint through the addCounterProfilePointListener
>>and addValueProfilePointListener methods of a ProfilePointDescriptor object.
>>The Samples are at a higher level and have their own ProfileSampleListener
>>interface for listeners which register with them.
>	Ok. I'm wondering why the choice of a observer-observee model inside
>	the profiler manager, instead of a pull method from the reporting
>	class ?
>	Perhaps, let me explain what I was hoping to do with the profiler.
>	We have a Cocoon application that runs over 4 load balanced
>	machines in production. I'm currently in the process of putting
>	together an architecture for building an administration
>	application for our production folk that can (among other
>	things) offer profiling information about actions performed in
>	production (the normal stuff, number of reports generated/hour, number
>	of login's/hour, memory usage, etc).
>	What I wanted to for them was create an admin application, that
>	would run on a separate machine somewhere, but obtain profiling data
>	from the production machines via some network procotol (eg. perhaps
>	SOAP the latest profiling data into a cocon pipeline and format it as
>	html or an svg chart, or into a swing based gui tool).
>	The data displayed could then also be updated on-demand via a
>	simple 'reload'. 
>	For our management however, I was also hoping to create a text
>	based reporter that would, at the end of the day facilitate them
>	with the latest daily data (total number login's, total reports
>	generated, etc).
>	The 2 reports contain different data, but are using the same profile
>	points.
>	Using a pull model, the different reporting implementations
>	could access the profilables directly and get/save the data when
>	it's required.
>	With a listener based approach you'd need to write a listener
>	class that is updated with profile point data, but accessed by the
>	reporting class when on-demand data is required. This incurs an extra
>	step as the listener implementation is essentially acting as a
>	pullable source for the data (or have I misunderstood something ?)
Actually in your case, you do not need to implement any listeners. 
 Simply obtain
references to the ProfileSampleDescriptors you are interrested in and 
call getValue()
or getSnapshot() each time you need a value.

The problem is that it is not really possible to build a truely pull 
based system which
would be efficient.  Especially across the network.

Lets take the Counter example:
For each event, the increment() method is called right?  Someplace, you 
need to be
keeping track of the number of times that increment() is called.  You 
could create
a class CounterSinceLastGetProfileProfilePoint or something but the flow 
of information
is still push until the data gets to the ProfilePoint.  Then at that 
point, the you can start
to pull be making requests of getCount() to the ProfilePoint.  I guess 
each call would
reset the count etc.
One problem here is that the rate at which getCount is called could 
actually be quite
eratic especially if the calls are initiated across the network.
A second problem is that it is not possible to have more than one client 
calling getValue()
because each call resets the count.
You will have similar problems with Max/Min/Average value ProfilePoints 
as well.

Now take the ProfileSample case:
The ProfileSample effectivly does the same thing as the 
above except that there can be more than one of them.  The data is push 
until the
ProfileSample, but from that point it is entirely pull.  The 
ProfileSample uses the
timestamps provided with each event rather than calling 
so they are much more accurate.
When a client does request data, it does not matter if they missed a few 
intervals because of some latency, the data, correctly intervalled, will 
all still be

>	The other thing is I would like to be able to change the sample
>	rates dynamically on particular profilables. With the reporting
>	tool pulling the data down (basically acting as the driver), this is
>	easy and can be made a part of the gui tool. I'm not sure how it could
>	be easily done with the listener approach ?
I agree, this is one area which is more difficult.  But what are some 
scenarios of
what you would like to do?

If you need to have hourly and per-minute reports, then you really need 
two sets of
sample history, so the ProfileSamples would meet your needs nicely.
If you need to really be dynamic.  Then we would need to add a way to 
add and
remove ProfileSamples at runtime.  Remeber that by doing so the data 
would start
when the ProfleSample was added.  There is no way to create information 
out of
thin air.  So this does not seem to me useful unless the generation of a 
daily report
is to take 24 hours to create.  Setting up a ProfileSample would have 
the data there
for you and the report would just get a snapshot when the report was 
scheduled to
be generated.

>	I think we can achive the same observer-observee idea with a
>	pull model, it just involves moving some of the driving code
>	into the reporting engine (at some abstract level) ?
Explain what you would like to do and I will see if I have any ideas.

>>>	The profile manager can be configured to automatically create a
>>>	set of listeners (samplers in this case) for particular profile 
>>>	points
>>>	on a particular profilable. Samplers configured in this way can
>>>	be accessed via the profile manager. The gui reporter essentially
>>>	iterates through the list of available samplers when building
>>>	it's menu's.
>	This is really nice, the format of the config file is good and
>	makes things quite easy to configure.
>	I'd find it nicer though if this configuration file configured the gui
>	tool (or some other reporting implementation) instead of the profiler
>	itself. Then we could facilitate the use of multiple simultaneous
>	reporting engines, each with different configurations.
See the mail in reply to Berin a few minutes ago.
There is nothing stopping a Reporting tool from having its own 
configuration file.  
The >Optional< profiler configuration file is only used to setup system 
wide ProfileSamples
and to define Descriptions for Profiler elements which will be made 
available through the
Descriptor classes.   It should be thought of as the place to define 
things which will be the
same for all users of the system. :-)

>	What are your thoughts about all the above ?
>	Awesome stuff though mate! I'm really looking forward to getting
>	this up and running in our application and in cocoon itself. :-)
Thank you.  I am glad to see all the interest in it.  All of the 
feedback has really made me think
about some areas that I had not thought of before.

Getting it up and running with Cocoon as it is now would require adding 
Profiler support to
the ECM.  I talked about that in the mail to Berin.  Should be neat 
though because much of
Cocoon could be profiled without changing any Cocoon classes.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message