CODEWITHSUNDEEP
tomcatjmxmbeans
Roland Huß
Roland Huß

Reputation: 2525

Tomcat: What's the meaning of a connector's "processingTime"?

What the meaning of Tomcat 6's MBean Catalina:type=GlobalRequestProcessor,name=http-0.0.0.0-8080 for the attribute processingTime ?

As far as I understand this, it means the processing time of a specific connector in milliseconds since startup. But when I measure this value every minute, I occasionally get back values which are much larger than 60k (i.e. I got delta values up to 1000k).

My question is, what milliseconds are measured. Real time or CPU time? Processing time of all connector threads accumulated?

What would be a good threshold for monitoring the processingTime?

Upvotes: 4

Views: 4327

Answers (1)

Eddie
Eddie

Reputation: 54431

Looking at the code, this is cumulative milliseconds of wall clock elapsed time as measured by System.currentTimeMillis() required to process each incoming request. Thus, this measurement for an individual http connector thread that is always busy (on a system with a stable system clock) shouldn't increment by more than 60,000 per minute. However, for the GlobalRequestProcessor, it can increase much faster than that depending on how many concurrent requests are being processed.

If, in a given minute, you receive 100 requests satisfied in one second and another 100 requests that block for 10 seconds before returning a value, then this counter for GlobalRequestProcessor will increase by 100x1x1000 + 100x10x1000 = 1,100,000 in that minute.

Note that since this measures wall clock elapsed time, if the clock on your server jumps forward, it will cause you to get erroneously large values for the elapsed time. That is, if the time jumps forward by one minute during a given servlet's processing and the servlet took 20 seconds to process the request, this measurement will tell you that the servlet took 80 seconds to process the request. If you happen to have a live request when the DST "Spring Forward" occurs, then you'll be told that that request took over an hour, meaning that this JMX measurement will increment by more than one hour. For the version I looked at, if the clock jumps backwards, you can end up decrementing this counter! Hopefully Tomcat 6 uses System.nanoTime() to avoid this dependence on system clock stability.

Prior to Java 1.5, there just isn't a good way to measure true elapsed time (as opposed to elapsed wall clock time). Since none of Tomcat 6.x and earlier require Java 5 or later, there is not really a way for them to measure anything other than milliseconds or to measure a true elapsed time that is independent of clock changes. (Unless there is use of reflection to do this. I haven't noticed any but I haven't searched for it either.)

Upvotes: 4

Related Questions