Profiling Problems in 4.4

Initial Description of Experience

If you want to feel the pain of using the 4.4 profiler read on ...

While trying to help a user on the mailing list I was reproducing his experience and "trying" to find a way to make it easier. This is meant to be a sad and slightly entertaining story that we need to fix. It is not an example of how to do anything.

This user has a client server application with the server running in Tomcat and the client being either a browser running dojo etc. or a RCP application. This interestingly provides 3 opportunities to use our profiler, however the user had no success with any.

The basic user install was to blindly install Europa with the latest TPTP 4.4, and have a separate agent controller directory even though everything was actually running on the same box.

So the first interesting problem is getting the AC install set up correctly. He figured out to run the setup script but didn't really know what he was doing or what jvm was picked. But, it would start.

Let's start with the server. The user was not using WTP and was attempting an attach scenario. This requires him to read and understand to instructions on how to change the canned Tomcat start up script he runs. Well where are those instructions for an end user? Lots of stuff on our site, but mostly pre-TI.

Step one is to search the online help in the workbench. There are several small problems that get in the way, but the trick is to know that you need help to "launch". Boating jokes aside, this word works for us TPTP weenies, but never crossed his mind. start up, attach, configure, all take you down different paths. So he searches the web site and then Google and doesn't find the help he needs because he is missing the critical word. Interestingly once pointed at the right web page, he can not figure out what to do, and is not sure which jvm level he is even using. So bright boy me thinks to suggest just using WTP to start and stop the server because then we do the ugly part for him, but because I have had my own problems in this space try it out first. I simply take a config that I have been using everyday for over a month to develop and test an application, and hit profile on server. Ok, so I am waiting and I know it will take a bit longer, but 5 minutes go by and even I give up. I see the java process was started, but nothing is happening and the tomcat server didn't actually come up. Nothing in the console window either. I conclude the IAC must not be working and stop everything, and just pretend to attached and test the connection, which takes a short while but comes back. Ok, try PoS again and it works. It turns out that the TI agent requires the agent controller to be up and running in order to connect etc.. But wait, I started all this in the workbench so why wasn't the IAC started?

Ok, so the WTP/IAC was not a good idea, as it exposes a huge user problem. Back to setting the tomcat start up script, looking closely we find that we need to pick a profiler parameter to say what kind of data we want to profile at start up time and not at attach time. (The user had tried some basic hello world stuff, interestingly with Java 1.4 and didn't need to do this. Note that the documentation, if you can find it doesn't say if there is a default, or that you can't specify all the profiler types at once and decide later. The realization now hits that in an attach scenario the user needs to have 3 different start up scripts plus one for no profiling for each application (total 12)

5 work days and a weekend have passed so far. The user has not come back to this task to finish it. Even though his job is to do performance work, logging out some timestamps was a quick way to get started. In the meantime he also tried ARM, but didn't realize he needed some instrumentation in order to collect data.

As yet we have not tried the RCP application and I don't think we even test browser configurations anymore. (yes it used to be tested and work for both IE and FireFox with the sun and ibm jre)

Yes this can be made to work, and yes this particular user may not be typical, but he is not unique.

Documentation is hard to do well, but we need to spend some time fixing this. Our web site is out of date, and during my trip through the online help I saw <<add a link here>> mixed in the text. A fresh walk through the scenarios will help a lot.

The profile on server scenario is simply broken from a user point of view. We have users that did use earlier releases of TPTP and now walk away because it just hangs on them.

It seems we can do some intelligent defaulting and make the start up script trivial to write like XrunpiAgent was, and thus enable an easier attach scenario.

A few hints and comments

I totally agree that documentation and web updates are important and need some updates.

Note that there is some cryptic documentation readme.txt on configuring run scripts in the directory that contains the TI agent (e.g., org.eclipse.tptp.platform.jvmti.runtime_4.4.1.v200709261752\agent_files\win_ia32) directory in the 4.4.0.3 release. There is a bugzilla filed against making standalone/script creation less painful. I have put a few of the scripts I use at TPTP-standalone-script-TPTP4.4.0.3.

I don't really use PoS so I can't really speak to this problem. I believe the claim that it is painful though...

There is a very good reason that you need to pre-specify the mode with which you will attach. It comes back to how JVMTI works versus how JVMPI worked. In JVMPI, you would take a performance hit when connecting with any agent because the VM had no way of knowing what events/functions would be used by the agent. Some JVMs (e.g., BEA) added some fancy command line parameters to disable some of the JVMPI commands for JVMPI users who wanted to assert at VM startup time that they would not use certain parts of JVMPI. JVMTI standardizes this concept of limiting peturbation. At VM startup, the JVMTI agent locks in the capabilities that it will require for the duration of the execution (yes, for you JVMTI experts out there, some but not all capabilities can also be set after the primordial stage but some of the important ones can only be set at startup. This way, the VM only needs to impact the performance subject to the capabilities that were selected. JVMTI pro: the richer interface provides more power. JVMTI con: using the richer interface efficiently has implications on launch (startup, attach, configure) that are more stringent from the earlier JVMPI interface.

I would actually suggest that one modify the startup script to read an environment variable that indicates the profiler that will be attached. In this way, only a single main startup script is required with a parameterized wrapper script that sets the environment variable then calls the underlying script.

suggestion

So how about a simple defaulting example that uses defaults that are equal to this

"java -agentlib:JPIBootLoader=JPIAgent:server=enabled;CGProf "

by doing this

"java -agentlib:JPIBootLoader=JPIAgent"

and in our material not just do HelloWorld, but show how to use with Tomcat and RCP?

I think the PoS problem simply needs to be fixed in 441 and asap.

-- CLE writes

• A tomcat or RCP example is a good idea. Anyone with experience w/ tomcat/RCP want to volunteer to make some scripts?
• Has anyone experimented with using environment variable instead of command line to set up profiling from command line? I've never used it...
  • [1]
• Anyone know if this works with all current Java5 vms?
  • If it works, it could avoid needing to change scripts...

Second try

I moved this content to the squiggly scenario here.