Thanks Craig :) Let me clarify: >* You haven't really described what you mean by "monitoring". People seem to be assuming you mean the usual performance monitoring that something like OptmizeIt does, but you could also be meaning something simple like "how many requests did my app process in the last 'n' seconds". Which extreme is closest to what you had in mind?
-- What I intend to do includes the 'usual' performance monitoring with a need to know which thread is taking the most CPU time, heap resources per application instance, which request is hanging/taking most of the CPU time, etc. I do not want to know data regarding all the installed apps on the JVM, but seggregate them purely on the ones specifically under webapps. Hope this helps :) Kailas -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 13, 2002 2:29 PM To: Tomcat Users List Subject: RE: Tomcat Profiling using Catalina API On Tue, 13 Aug 2002, Simha, Kailas wrote: > Date: Tue, 13 Aug 2002 13:37:58 -0400 > From: "Simha, Kailas" <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: Tomcat Profiling using Catalina API > > Thanks Will. > I understand that all 'optimizers' will have a specific overhead and > sluggishness associated with them, due to their sheer nature of operation. > I am trying to map tomcat operations -per application, per context, per JVM > in an environment hosting multiple JVMs and tomcat instances. I also need > the ability to differentiate between two instances of the same application > running in such an environment. My approach purely has been from this point > of view. The tools I tested out do need extensive customization to suit our > needs, and if it is going to take a 'little more' effort to build one > ourselves, we are likely to take that route. Once again, I am just exploring > the possibilities, but seriously. > Purely for mapping JVM, I know that we can use 'hprof' that ships with the > JDK. I would want to do the same thing, purely from the perspective of > tomcat. > In a nut shell, I would want to capture the profiling data of a tomcat > instance in a servlet or applet, with the ability to switch between JVMs and > tomcat instances. > JVMs > | > Tomcat Instances > | > Contexts > | > Applications > | > Instances, threads, resources and session > information > Any insights would be greatly appreciated. > Thanks > Kailas > Two quick thoughts (not likely to be helpful, but they are important): * You haven't really described what you mean by "monitoring". People seem to be assuming you mean the usual performance monitoring that something like OptmizeIt does, but you could also be meaning something simple like "how many requests did my app process in the last 'n' seconds". Which extreme is closest to what you had in mind? * Because Tomcat runs all the installed apps in a single JVM, and aggressively shares resources, it's virtually impossible to identify which resources are used by which webapps. Just as a simple example, request processing threads are shared across *all* installed webapps, so there is no way to allocate their behavior to just one. It all comes down to what you think you're trying to measure, and that certainly is not clear. Craig > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 13, 2002 1:33 PM > To: Tomcat Users List > Subject: Re: Tomcat Profiling using Catalina API > > > From: "Simha, Kailas" <[EMAIL PROTECTED]> > Sent: Tuesday, August 13, 2002 7:00 AM > > > > 4. Ofcourse, there is this problem of overhead and sluggishness when using > > OptimizeIt and thus it is not preferable on production systems. > > Umm...You do understand WHY systems like OptimieIt et al bring your code to > a screeching halt, correct? That they don't do it because they like doing > it, they don't do it because they're written really badly, and that all > profilers suffer from slow performance? > > The point being, that if performance is why you're trying to delve into the > arcane realm of JPDA, you're likely to not get very far. > > How about redoing from start and come back with what you want to do with > Tomcat, and why you feel JPDA is the way to approach the problem. It may > very well be a good solution, but start with the high level and work from > there, let us in on the thought trail that got you here. > > Regards, > > Will Hartung > ([EMAIL PROTECTED]) > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > ---------------------------------------------------------------------------- -- > Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. > > ============================================================================ == > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ============================================================================== -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
