On Tue, 13 Aug 2002, Simha, Kailas wrote:
> Date: Tue, 13 Aug 2002 14:41:41 -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 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
Now *that* is a precise definition :-).
> 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 :)
Good luck ... reliably untangling the impact of a single webapp seems like
a real challenge in a shared environment like a servlet container.
> Kailas
Craig
>
> -----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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
