> From: "tom ly" <[EMAIL PROTECTED]> > Sent: Thursday, May 13, 2004 8:18 AM
> My team is thinking about getting a profiling tool. Does anybody have any experience with either tool? What are your thoughts about each one? I've had mediocre success with any of them. They all seem to basically do the same thing, they're all pretty darn slow, and they've never really told us much that we didn't know already. With our J2EE app, a lot of our issues turned out to be contention in the container, something none of these tools were able to narrow down, isolate, or identify (even some of the $$$ "enterprise" tools). I've tried these tools, yet I still have better luck with strategically placed Log4J statements, occasional thread dumps, and verbose GC chatter. Even the stock hprof is basically usable, once you get the hang of it. It's not that the tools aren't good, its just, to me, for the money, they're not a good value over things that are readily available. As a developer, you typically KNOW what's slow anyways, and a bit of logging instrumentation goes a long way. If user X clicks on button Y and "it feels slow", that alone narrows down the problem. For monitoring some behaviors, try BEA JRockit, it comes with a nice memory profiler system built in. It also has a method profiler. Finally, if you're looking for production logging, none of the tools mentioned will help there at all. They're too expensive (performance wise) to run. If you have NO IDEA why you code is slow, these tools MAY help you. But in that case they overwhelm you with so much data, that it's pretty much hopeless. "Wow, StringBuffer is the culprit." Yea, that's real helpful information. We only call it 8000 times throughout the app. It takes diligence and patience to tune your app, tune it one piece at a time, make sure you can duplicate your results through load testing, and make sure you only tweak one knob at a time, otherwise you may not know what made it faster/slower. Tune early, tune often. One of the things we did was we wrote our own logging JDBC layer (they are all simply interfaces, after all) which checks how long SQL queries take, and logs those that hit a specific threshold. Dumps the SQL, dumps the bind, whole ball of wax. Then we can go through that log on a regular basis to tune queries, the DB, or the code. That helped a LOT for our system. Regards, Will Hartung ([EMAIL PROTECTED]) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
