Leif Mortenson wrote: > > > Then Marcus would also like to be able to have scheduled Profile Samples > which would collect data for certain periods of time each day. (?) > > To make matters worse, the interface to do all this has to be fast, simple > and ellagent. :-)
We also have to keep in mind the intended use for the Instrumentation system. The intended use is to determine "hot spots" in the system, to determine system health, and to aid the developer in debugging. Any other use is not a good use of an instrumentation system. We should not mix *business* concerns with a *developer* oriented tool. >> > The question is how should this API be secured. Who should have >> access >> > to it >> > etc. Currently, which ProfileSamples are to be made available is >> up to >> > the system >> > administrator. If anyone can add or remove these ProfileSamples at >> > will, it could >> > break other systems which are using them. Anything added outside >> of the >> > ProfilerManager is controlled by the user code which does the adding. >> >> Could you explain your concerns a little better? The only three classes >> of people who should have the right to view profiling data are the >> sys-admin, the tester, and the developer. Any sampling point that >> caters to a different class of people is not a good sampling point. > > > > I was thinking that there are lots of places where the profile data can > be used for business purposes etc. Say on a e-commerce site. You may want > to collect data which showed things like the number of times an item was > placed into a visitor's basket or purchased. Page views per second etc. > > Data sets like this become a resource of the system and should not be able > to be suspended or removed. Business specific data such as that should be captured in other ways. It is trivial to write a SQL query that looks at all the times an item was added to a basket, and purchased. Perhaps the system would be a duplicate, or perhaps the system will have two IntrumentManagers running simultaneously. The point is, we have to enable remote diagnosis, and we have to enable performance tuning. >> We can use JAAS to ensure that the GUI can be attached by a properly >> approved user. > > > > Not familliar with JAAS yet, but it should be possible to allow different > actions on the profile data depending on user role. I was thinking of using it merely to handle the authentication policy so that a remote user can diagnose the health of a running system in a secure manner--so we don't have to write all the authentication code ourselves. > > I still need to work out some issues for how to deal with listeners for > remote systems. Right now if a remote listener registers itself with a > profile point, the code which uses the profile point would be really > suffer a big performance hit. So I don't think that should be allowed. > Even the current ProfileSample Listeners could have a lot of traffic. > I think that anything that goes across RMI should be done asyncronously > to prevent a performance hit in the code being profiled. Currently, the > same thread flows up through the ProfilePoint to all the listeners and > ProfileSamples and back. This is quite efficient now, but it would not > be if there was a two way socket communicate thrown in there. That was one of the concerns I had with the ProfileReport interface I had. I wanted something where information could be sent in a controlled manner--but streamed. However, one way to handle remote data is to send the information in "frames". What is important is that the remote user gets the information, not every last sample. Therefore, if the listener gathers enough information to send a frame of data (i.e. the PerSecond listeners and PerMinute listeners) we send a chunk at a time. That way the system isn't blocking for too long. > One idea is to allow clients to connect as a listener with a requested > update interval. Say 1 second. As well as a flag which triggers a call > each interval, or only for intervals which have new data. The > ProfilerManager would then use a pool of runner threads to service those > listeners in the background. Yep. That's part of the solution. caching the data so that it is sent properly helps as well. That way we can use the java.util.zip package to compress the data on the line. The lower bandwidth will allow us to squeeze more information per frame. > I think those kinds of events would actually serve all of the requests > that I have heard so far. Actually a little better than the current > Listeners which actually provide too much information. > > Currently the charts in the ProfilerFrame have their own threads which > request snapshots each second. If I modified them to register as > themselves as Interval Listeners, as above, then the timing of their > updates would be driven by the ProfilerManager, removing the need for > them to each have a runner thread. Definitely a worthwhile approach. It would be benificial to keep the per thread approach. However, the interval approach would have to be on a separate thread/timer than the main sampling thread. The reason being that the output logic can introduce delays that would cause an unacceptable amount of jitter in the result set. >> That is not an uncommon problem. People who use Cocoon are well >> familiar with those issues. > > > > Yes, but I'm sure that doesn't stop them from grumbling about them any > though :-) You're right. > I was actually trying to think of how to set up the Profiler in something > like Phoenix. Currently, you could have one management console. But each > app would have to have its own ProfilerManager. I don't think there is > a way to create a single ProfilerManager which would be shared by multiple > application because they were each loaded by a different Classloader. Well keep in mind that the core Framework/Excalibur code is loaded in the base classloader. Each application is *I think* in a child classloader of that one. Of course, I could be wrong. >> That way, we can enable remote monitoring, while aleviating security >> administrator's fears of publicly exposing critical information. (that >> can kill a project--I've had it happen to me). > > > > I think that role support should be built into the PM, but the > encryption issue > can probably be handled by the code which actually services remote > requests. > Maybe register an AltRMIClient in the same JVM to the PM. Then remote > clients > would connect to that AltRMIClient via RMI. You could do the same for > HTTP or > HTTPs clients for example. That makes it easy for new protocols to be > added > without adding any clutter to the PM. Each connector would just be > connecting > to the PM using the normal APIs Sounds reasonable > >> > I agree that there should be a way to serialize output data in >> whatever >> > format you >> > want. But do not confuse that with the profiler.sampledata file >> which >> > is currently >> > being saved at regular intervals and shutdown by the ProfilerManager. >> > This file >> > really only has one purpose. Making it possible to preserve the >> state of >> > ProfileSample data across invocations of the JVM. That means that the >> > file must >> > be read as well as saved. If this file format can be changed then the >> > reading also >> > becomes very complicated. I am all in favor of adding a way to >> make other >> > snapshots to any file format. Maybe implement something like the >> > targets in the >> > logger. >> >> So, in order to solve this problem, we should have additional listeners >> who's responsibility is to save the data in whatever format we need? > > > > Ok, it would be nice if this could piggy back the regular client interfaces > though. > > Maybe have a report generator client which requested to be notified > every 30 > minutes by a certain ProfileSample... That report could then write out > a CSV > file or something. Ok. I just wanted to get your thoughts on the proper way to do this, as well as my idea. ---------------------------------------------------- Sign Up for NetZero Platinum Today Only $9.95 per month! http://my.netzero.net/s/signup?r=platinum&refcd=PT97 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
