Call stack trace

[Dave Chen]

Hi,

I am looking for a framework to embed into our application for performance monitoring. Java Simon looks like is the right tool for us.

I downloaded the latest version and was very impressed. However I have a couple of questions.

1. Can I use it for call stack trace in addition of counter/execution time? I want to use it to trace a method call from top to bottom, such as Start method1 calls method2 and method 2 calls method 3 End.

2. How much memory overhead does it add on? Can I use it in production for long period of monitoring?  

Thanks,

Dave

[Richard Richter]

Hi Dave

Welcome to our group! Answers:

1. Not easily, but it depends on what you want exactly. When Stopwatch
measures something, it does not care that much about the context, e.g.
what are the parameter values, from where the method was called, etc.
Doing this in a general fashion may be something Java Simon is not
built for. However if you are interested in particular corner cases,
you can somehow build up the name of the Stopwatch, so it contains the
context. That way you will have different Simons for different callers
for instance.

Something like:
Split split = SimonManager.getStopwatch("base.name." +
buildNameFromStackFrames()).start();
... measure
split.stop();

Of course, be carefull not to end up with tons of various stopwatches,
extra long names (slower equals), etc.

Another special case we do with Simons is how SimonServletFilter
gathers every Split for a particular HTTP request using thread local
store and Simon Callbacks. This allows us to report slow request along
with all Splits involved. Our future plans are to add "attributes" not
only to Simons, but also to every Split. This way we will be able to
store parameters of calls if necessary - for a particular call. So
when you see slow HTTP request, you know also what kind of input
caused it, what were parameters to SQL for instance, etc. Right now
Split don't have attributes yet. Would that help you?

So maybe you need different library altogether - and maybe you can
bend Simon using our Callback mechanisms that allows you to do a lot
of interesting stuff.

2. Depends rather on how many Simons you create. Also if you use
Callbacks that store long history of splits in Stopwatchs' attributes
it will get much worse, etc. It is small library I think, but I'd
rather monitor my heap with profiler (or JVisualVM) to find out how
much it eats in my case. If it leaks, it should be reported, but there
should not be anything like this. If you want to get rid of older
Simons (imagine you create names on the fly and you're not interested
in them), simply add your timer that checks all Simons and their
getLastUsage() (ms timestamp) - and destroy those.

A lot of stuff is left to the user of the library when needed.

I hope this helped you to decide. ;-)

Regards

Virgo

> --
> You received this message because you are subscribed to the Google Groups
> "javasimon" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to javasimon+...@googlegroups.com.
> To post to this group, send email to java...@googlegroups.com.
> Visit this group at http://groups.google.com/group/javasimon?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Gérald]

Hi Dave,

Richard answered to your question for the core part of JavaSimon.

I am going to answer only about the CallTree plugin: this callback+web console plugin gathers information using contextual information stored in a ThreadLocal. At the end of the call, this call tree/stack is kept only if the global duration exceeds the specified duration. Furthermore, only the last call tree snapshot is kept as a Simon attribute, so memory consumption is constant over time. But you could change this strategy, to keep the 10 last ones...

Gérald