|
|
|
Back to newsletter 038 contents
My profiler imposes too heavy an overhead on my J2EE application, is there an alternative?
I'm afraid that you have discovered that you need to keep trying different tools in different configurations until you can find one that gives you reasonable statistics without too much overhead. You can usually run the verbosegc option to get GC stats, and as we said in last week's QOTM about Xprof you can get some information almost for free using the Xprof profiler (assuming you are running HotSpot of course), but if you want to profile a heavy duty server you need to use something with very low overhead. Perhaps a J2EE monitor could help, look on http://www.JavaPerformanceTuning.com/resources.shtml#ProfilingToolsNotFree and they are listed first. There are other tools listed there and free ones too, listed at http://www.JavaPerformanceTuning.com/resources.shtml#ProfilingToolsFree .
One of these tools usually works sufficiently to give you useful stats, but in those cases where they don't, you need to instrument the code yourself. I can recommend a good performance tuner to come and consult if you have the budget -;) otherwise, it will be a matter for you to keep trying until your performance tuning expertise has increased sufficiently to be able to infer what to use and where. Sorry, but there are no magic bullets in this situation, it takes intuition or experience to extract the information identifying bottlenecks in this situation. If I ever come up with a step-by-step reliable procedure for identifying J2EE bottlenecks in general, I'll publish it.
Profiling J2EE applications is challenging. The J2EE monitor vendors are trying their hardest to make it simpler, and their products certainly give you a boost in identifying performance problems, and some types of J2EE bottlenecks that used to be really difficult to identify can now be found relatively easily. But J2EE applications are often of such complexity that there can be bottlenecks which are difficult to identify without jumping through hoops.
The JavaPerformanceTuning.com team
Back to newsletter 038 contents