tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Checkoway <dchecko...@gmail.com>
Subject Re: how to track tomcat throughput?
Date Wed, 18 May 2011 11:31:00 GMT
I've messed around a bit, and I figured out a more reliable way to do
it...but it's pretty nasty.  Basically I'm iterating and grabbing the
"requestCount" attribute from all of the RequestProcessor mbeans, and just
tallying them up.

Like I said, it's nasty, since you need to know the max possible # of
RequestProcessor beans, there are "gaps" in the sequence, etc.  I'm hoping
there's an easier way to get just a single JMX-exposed attribute
representing total requestCount.

Possible?  Wish list item...open a bugzilla ticket?  Bueller...Bueller...?
:-)

Dan

On Tue, May 17, 2011 at 4:22 AM, Dan Checkoway <dcheckoway@gmail.com> wrote:

> I'm looking for advice on the most reliable & efficient way to track tomcat
> throughput...preferably via JMX.  I've written a simple app that uses JMX to
> grab the "completedTaskCount" attribute on the Executor.  My assumption was
> that the Executor's completedTaskCount would be a fairly accurate way to
> watch, in real-time, the number of HTTP requests served...and a heck of a
> lot simpler than just counting access log lines.  Basically the app grabs
> the completedTaskCount every 10 seconds and does a simple "how many more
> since the last time I checked" rate calculation.
>
> But what I think I'm seeing is that the Executor's completedTaskCount grows
> at a rate higher than the actual number of HTTP requests being served.  So
> I'm wondering...is a shared Executor being used for purposes other than just
> serving requests, and if so, what other types of tasks are being executed?
>
> Is there any other attribute exposed by JMX that might be a more reliable
> way of counting actual HTTP requests served?  Is there a simpler way of
> accomplishing the same goal that doesn't involve access log analysis?
>
> Thanks,
> Dan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message