Better yet do you want to know how the application uses Tomcat resources? To do what Leon mentions requires a profilier that is approved for production use or have the developers write timers in the code for critical measurements say around time it takes for a request versus jdbc calls some may have to be an aggragate of many calls if that is what is happening like say 1000 calls to get data for one servlet method request. If you can have measurements around the edge of your app and servlet container measuements you should bet set for isolating performance issues for some time.
Regards, -Tony --- On Wed, 11/19/08, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > From: Leon Rosenberg <[EMAIL PROTECTED]> > Subject: Re: Hard limits in Tomcat? > To: "Tomcat Users List" <users@tomcat.apache.org> > Date: Wednesday, November 19, 2008, 7:23 AM > I think the question you wanna ask yourself first is, > do you want to monitor tomcat or do you want to monitor > your application? > > regards > Leon > > On Wed, Nov 19, 2008 at 3:18 PM, Kees Jan Koster > <[EMAIL PROTECTED]> wrote: > > Dear Chris, > > > >>> I am setting up a monitoring system for Tomcat > servers and I am looking > >>> for hard limits in Tomcat servers in general. > >>> > >>> I found a few so far: file descriptors, memory > pools (ok, these are jdk > >>> limits) and thread pools. > >>> > >>> Are there any other hard limits that I can run > into? > >> > >> I would call these soft limits, as they can be > changed. > > > > Ah, sorry for the confusion. I should have asked for > limits that are hard at > > run-time. Thread pool sizes may be editable, but they > are fixed once Tomcat > > runs. > > > >> What limits are relevant? For instance, Java > doesn't allow you to have > >> any method with more than 64k of code. I suppose > that's of little > >> consequence to a running JVM, since the code would > never be loaded. > > > > Yes, I ran into that limit for a generated servlet > once. This is not the > > kind of limit that I am looking for, as it is caught > compile-time, not > > run-time. > > > >> If you are going to count memory (heap?) and file > descriptors, I suppose > >> you could also count CPU time, since that is a > limitable resource on > >> *NIX systems. > > > > Hmm. It's really only useful if I can monitor both > the maximum available > > time and the used time. I have no idea how I would > measure that, even at > > unix level. It gets even more messy in virtual > servers. > > > >> If you really are talking about soft limits, then > you probably also want > >> to see the number of requests accepted but not yet > being handled > >> (controlled by the <Connector>'s > "acceptCount" attribute), the number of > >> request processors (is this "thread > pools" above?), the number of > >> connections total/available/used in JDBC > connection pools. > > > > > > Ah, that is interesting too: queue fill levels that > should under normal > > circumstances be more or less empty. Much like the > > ObjectPendingFinalizationCount. Thanks for that. > > > > How would I use it, though? In my Tomcat acceptCount > has a value of 100. > > That's probaly an upper limit. What is the > 'un-use' property that goes with > > this upper limit? > > > > What MBean can I talk to about JDBC connection > pooling? > > > > -- > > Kees Jan > > > > http://java-monitor.com/forum/ > > [EMAIL PROTECTED] > > 06-51838192 > > > > Human beings make life so interesting. Do you know > that in a universe so > > full of wonders, > > they have managed to invent boredom. Quite > astonishing... -- Terry Partchett > > > > > > > --------------------------------------------------------------------- > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
