I wanted to use inspectIT to find why my web application was slow and I finally realize I couldn't for 2 main reasons:
In order to see where the JVM passed its time handling one specific request, I must declare in a Profile Configuration all the classes I want to "watch" in order to be later analyzed in the "Invocation Sequence" tool. But then, as I don't know where the contention points are, I want to declare all the classes of my application in an HTTP & Timer Sensor definitions in my new profile, using "mypackage.*" notation for class name.
If I activate this new profile and restart my Tomcat server, it will never stop (or is so slow for starting that I killed it after having waited for more than 2 hours, hanged at "rocks.inspectit.agent.java.javaagent.JavaAgent premain" log line)
That's 3 years since I developed a tool that was using a stacktrace sampling mechanism in order to handle that use case ( http://webapp-watcher.com/overview.html ), would it be possible for the agent to be configured in a sampling way (that is to say without having to instrumentalize the classes), so that we can later on analyze where the JVM passed its time without knowing where to look before launching the application (so before launching the agent)?
First about your profile that includes all with mypackage.*. Sure that the Tomcat is stuck simply the instrumentation is huge. It was never intended to instrument so many classes/method and of course this would not even work out as overhead you introduce is too high.
Still you could start with the small instrumentation, like only instrumenting your services, SQLs and maybe some classes that you suspect could be problematic. Then test and check results, you could at least find out where the main problems are and then increase instrumentation in that area to find out more. This is how we are doing it for years now, even with the applications that we don't know at all.
About sampling, yes it's a very nice feature that we also want to have (see ). We did some work on this topic, but we far away from realization. I am not aware of webapp-watcher, I will check it out, is it also open source? If you are interested in helping us out in creating the sampling approach let us know, maybe this would speed things up.
If you have any other proposals or you find any bugs please let us know, this helps us in improving the quality and usability.
Thank you for the use case explanation that confirms what I feared: I think I can't use inspectIT as is for now to search for a performance issue in the webapp I'm working on (an open source project called transmart which is really huge in terme of number of classes and places to search for problems).
Perhaps I could work on having the sampling mechanism working in inspectIT but I must first look at all the protocols & communication API between the Agent & the CMR. Moreover I'm wondering if that could potentially have an impact in the current architecture design...