performance impact of jvmti when debugger isn't connected?

Question

We recently pushed a web application (tomcat 5.5.x web app) into production and it started exhibiting odd behavior today. We don't see this behavior in any development or pre-production environment.

Our only view into the production system at runtime is logging. Although they can tell us what happened they can't really help us diagnose why it is happening.

We have had to reload the context twice yesterday to resolve the issue.

I was considering starting the production tomcat server with jpda active. This would allow me to connect a debugger to the application if the problem reoccurred (after removing tomcat from the pool of servers servicing user requests).

You clearly pay a performance penalty with jpda when a debugger is connected. However, I was wondering what the "cost" was when a debugger wasn't connected? I suspect that the overhead associated with "listening" for a debugger might be pretty minimal. Before I spend a few hours on performance measurements I was hoping that someone could point me to documentation that might clarify this?

java version "1.5.0_17" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_17-b04, mixed mode)

on RHEL 5.3

Thanks!

Carlos

Answer 1

I don't have a quantitative answer, but the performance impact is very small; it's architecturally very similar to DTrace, and basically if you don't connect an external tool and activate events, the test points have to do very little work; they also do very little work for event classes that aren't active.

Answer 2

First of all, why not Tomcat 6?

Then, if you deploy to Sun Java 6 you can attach jconsole or jvisualvm to it and get a lot of performance metrics that may help you in pinpointing the problem. Notably jvisualvm can profile your application!

(and I believe the overhead of having an application being ready to attach a debugger is minimal)