At 07:55 7.11.2000 +0100, you wrote:
>Well, I don't :-) One thing might be not to check the time per call, but
>the number of calls per second. That require less system resources: set
>off a timer, set an increment to zero, tick the counter for each call,
>and when the timer hits 1 (or 10, or 60 or something) you check the
>counter and divide by number of seconds. That could give interesting
>metrics (call/second) but would be less intrusive on performance.
It's interesting for benchmarking and stress testing a bean. But you'd also
need to build micro benchmark tests that fed the bean with as many calls
per second as possible to be able to compare the results.
This is of course useful as well but not quite what I was after. I'm more
interested in being able to plug in a monitor to a "live" system, to be
able to easily visualize which parts of the system take up the most
execution time, which users/groups are accessing them and how often, and
break it down to application/bean or even method level. This should allow
the admin/developer to identify the parts of the system that should be
considered for increased optimization and find potential bottlenecks. I
think it's valuable to be able to monitor a deployed application in its
normal usage scenario. This is something you will want to do if you plan on
hosting services, for example.
Anyhow, there are probably more than one part of the architecture that can
publish interesting results to the same metrics topic. Invocation layer was
just the most obvious one so I decided to give it a shot first.
-- Juha
>
>/Rickard
>
>--
>Rickard �berg
>
>Email: [EMAIL PROTECTED]
>http://www.telkel.com
>http://www.jboss.org
>http://www.dreambean.com
>
>
