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 17:37:58 GMT
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


-----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>


Mime
View raw message