Gotcha...yeah, it would be trivial to slap an AtomicLong counter in a filter, but I'd hate to double the synchronization hit if tomcat already has this counter available centrally.
I'd like to hear an authoritative answer from the tomcat devs, if possible, as to whether tomcat is already doing this centrally, and maybe just not exposing it? Dan On Wed, May 18, 2011 at 7:45 AM, Jess Holle <je...@ptc.com> wrote: > I've done a servlet request filter for this and many other such things. > > I've always been a bit surprised by how little of this data Tomcat collects > -- but that's fine as one can do a servlet request filter that will work in > any servlet engine and collect everything you want. > > That said, collecting some of this information becomes a lot more > challenging with asynchronous requests, which is something I've not yet > tackled. For instance, it's easy to track the CPU usage for each > synchronous request (obviously from the servlet filter on down in the call > stack, not counting the Tomcat calls before/after this), but not so easy for > an asynchronous request... > > -- > Jess Holle > > > On 5/18/2011 6:31 AM, Dan Checkoway wrote: > >> 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 >>> >>> >
