tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simha, Kailas" <kailas_si...@merck.com>
Subject RE: Tomcat Profiling using Catalina API
Date Tue, 13 Aug 2002 18:41:41 GMT
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:craigmcc@apache.org]
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" <kailas_simha@merck.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: 'Tomcat Users List' <tomcat-user@jakarta.apache.org>
> 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: willh@msoft.com [mailto:willh@msoft.com]
> Sent: Tuesday, August 13, 2002 1:33 PM
> To: Tomcat Users List
> Subject: Re: Tomcat Profiling using Catalina API
>
>
> From: "Simha, Kailas" <kailas_simha@merck.com>
> 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
> (willh@msoft.com)
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
>
>
>
----------------------------------------------------------------------------
--
> 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:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:tomcat-user-help@jakarta.apache.org>


------------------------------------------------------------------------------
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:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message