I am a fanatic about avoiding unnecessary overhead by tracing tools....especially for performance monitoring.
End users therefore need help finding just the right set of classes to instrument -- enough classes to show the info they need, but not so many as to cause excessive overhead.
I can think of two algorithms that will help an end user discover the names of helpful classes.
I'm sure others can think of more.
Here is the feature request: Allow programmers to write algorithms that will "suggest" the names of classes that can be helpful.
a) InTrace will allow end users to chose an algorithm.
b) InTrace will run the algorithm against the app being traced.
c) The algorithm will return to InTrace a list of suggested classes to instrument.
d) InTrace will display the list to the end user, with a check mark box (or similar) next to each class name.
e) End users will place check marks next to certain class names...then click a button labled "Intrumented all checked classes" (or similar).
f) InTrace will add instrumentation for all classes with check marks.
Here are two example algorithms:
Algorithm 1: Stacktrace mining
Consider SOA systems that use JDBC.
Capture a stack trace (without throwing a java.lang.Throwable) from inside certain methods in the JDBC driver. Here is one such method:
http://docs.oracle.com/javase/6/docs/api/java/sql/PreparedStatement.html#executeQuery()
Each class name referenced in the stack trace is a class that would be helpful (IMHO) for understanding application performance.
Algorithm 2: Import mining
Say that we've instrumented just a single class in a JVM. If one particular method shows a performance problem, the next performance troubleshooting step for me is to look at performance of all classes/methods invoke from the initial one.
The import statements for the original class contains a super set of all possible methods invoked.
Wouldn't it be possible to further trim down the list to show just those classes invoked from a single method?
I am a fanatic about avoiding unnecessary overhead by tracing tools....especially for performance monitoring. End users therefore need help finding just the right set of classes to instrument -- enough classes to show the info they need, but not so many as to cause excessive overhead.
I can think of two algorithms that will help an end user discover the names of helpful classes. I'm sure others can think of more.
Here is the feature request: Allow programmers to write algorithms that will "suggest" the names of classes that can be helpful.
a) InTrace will allow end users to chose an algorithm. b) InTrace will run the algorithm against the app being traced. c) The algorithm will return to InTrace a list of suggested classes to instrument. d) InTrace will display the list to the end user, with a check mark box (or similar) next to each class name. e) End users will place check marks next to certain class names...then click a button labled "Intrumented all checked classes" (or similar). f) InTrace will add instrumentation for all classes with check marks.
Here are two example algorithms:
Algorithm 1: Stacktrace mining
Consider SOA systems that use JDBC.
Capture a stack trace (without throwing a java.lang.Throwable) from inside certain methods in the JDBC driver. Here is one such method: http://docs.oracle.com/javase/6/docs/api/java/sql/PreparedStatement.html#executeQuery() Each class name referenced in the stack trace is a class that would be helpful (IMHO) for understanding application performance.
Algorithm 2: Import mining
Say that we've instrumented just a single class in a JVM. If one particular method shows a performance problem, the next performance troubleshooting step for me is to look at performance of all classes/methods invoke from the initial one. The import statements for the original class contains a super set of all possible methods invoked. Wouldn't it be possible to further trim down the list to show just those classes invoked from a single method?