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 <dchecko...@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 >
