On 18/05/2011 13:21, Dan Checkoway wrote: > 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?
GlobalRequestProcessor (one per connector) is the best you'll get. Mark > > 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 >>>> >>>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
