Ryan Shaw wrote: >Hi Berin, > >Leif is not here yet so I'll try to answer your questions. This is >totally his baby, though, so take my answers with a grain of salt. > >||| 1) Are you using the LogEnabled interface instead of the Loggable >||| interface? > >LogEnabled. > >||| 2) Can you extend the example program to provide information about >||| the ProfilableComponentManager itself--with information about >||| lookups/second and releases/second? > >So the PCM already instrumented for memory so this would just be >a matter of adding profile points for lookups/releases and adding >them to the config. > The PCM is actually extremely light weight. I am actually hoping to be able to get rid of it completly by merging the changes into the ECM. All it would require is added two more steps to the component initialization phase. One for Profilable and one for ProfilerManageable. The guts of the PCM are actually in the ECM.
If that change was made it would be very easy to add ProfilePoints into the ComponentHandlers to be able to profile the lookups and releases on various components. This would be very useful as it would enable you to do a lot of profiling without having to add any Profilable code into the individual components. I would have to do lots of performance tests to make sure that this did not do any harm, but the ProfilePoints are specifically designed to be VERY lightweight when a ProfilerManager is not pressent. Even with a ProfilerManager connected, they still have almost no effect on performance until listeners are registered. > >||| 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. I would actually love to see Phoenix applications made for this. One as a Swing GUI, and another as a Servlet based tool. Is there any other work going on GUI wise for Phoenix management. I have read talk of it. But... No reason why this can't be the start. > >||| I liked the fact that the memory was well managed. When I tested it >||| with 100,000 doAction() events, I never exceeded 11M of max memory >||| in the JVM. That is a problem with JMeter's GUI event listeners. > >Leif is a memory ninja. :^) > >||| 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. >||| Also, how exactly is the ProfilerManager listening for events? > The ProfilePoint has a setProfilePointProxy() method which is called by the ProfilerManager when the ProfilePoint is registered by its Profilable component. The ProfilePointProxy does not contain any reference back to the ProfilePoint. This removes the need for the ProfilerManager to be in the loop for the destruction of ProfilePoints and their Profilable components. The ProfilePointProxy object reference is private to the ProfileProxy and this safe. When an increment() or setValue() method is called on a ProfilePoint it checks to see whether or not a Proxy has been set. If so, the call is propagated to the Proxy. The proxy then checks whether or not any ProfilePointListeners have been registered. If they have, then they are each called, otherwise the call is thrown out. Up to this point there has been no need to do any kind of synchronization so this is VERY fast. Now a ProfilePointListener can be anything. But one implementation that is built into the altprofile system is a ProfileSample object. This object comes in a variety of flavors. The CounterProfileSample takes increment() events. and the AverageValueProfileSample, MaximumValueProfileSample, and MinimumValueProfileSamples each take setValue() events. ProfileSamples are used in places where the profile history data needs to be maintained for future use. The ProfileSample takes care of breaking the individual events into sample periods which together make up the history of the data collected from a ProfilePoint. ProfileSamples can also have listeners registered They are fired with information that has been filtered through the sample. For example if a MaximumValueSample receives the values 10, 100, 50, 60, 90, and 101 in that order within a single sample period. The ProfileSampleListener will only notified of the values 10, 100 and 101 because those are the only significant values. Profilables, ProfilePoints, and ProfileSamples all have Descriptor classes which can be obtained throught the ProfilerManager. These Descriptors are used to give clients access to the Profiler elements without giving them access to anything sensitive. 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? So far it is just a search and replace problem. It will get more complicated later the more people begin to play with it. Cheers, Leif -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
