1277 days ago
QCon 2009 Impressions: Java Performance with Kirk Pepperdine

I’m at QConSF all this week, so you’ll get to hear my impressions of every session I go to. Lucky you!

My first all-day tutorial at QCon 2009 was “Java Performance Tuning” with Kirk Pepperdine. He spent much of the day encouraging us to spend time classifying the nature of the performance problem before trying to actually solve it.

Specifically, he asserted that you can diagnose much of an application’s problem without knowing anything about its source (or even ever having seen its source). His methodology basically boils down to this: First, use monitoring tools to classify your problem:
1) Is it user cpu bound, io bound, system cpu bound or memory bound?
2) Is it Application layer, JVM layer, or OS layer?

Then, and only then, use a profiler plus your knowledge of the source to pin the problem down and solve it.

Basically, most of the morning was about codifying what’s really common sense (but what isn’t at the end of the day?). In particular, you should measure and monitor, then make hypotheses based on monitoring, then use profiling to pinpoint the problem and support your hypotheses. Fix the problem and re-sample your monitoring. Repeat until the user is happy.

I’ve seen this many times on projects that have performance problems. Each developer has his own pet theory based on a hunch and will not let go. If more projects started with measurements and testable hypotheses, they’d be in a much better place.

Pepperdine also introduced several tools, the best of which was one I’ve been searching for but couldn’t find: IronEye SQL. He confirmed what I’d suspected–that the project was dead. But I was happy to discover that he personally had the source and was trying to revive it! Yay!

The best technical tidbit I got out of the session was some insight about Collections classes that have a medium-term life. It’s possible to have a Collections class (say a LinkedList) live just long enough for some of its plumbing to make it into the “old” generation. If that happens, then even if that LinkedList goes out of scope and is eligible for garbage collection, it won’t actually get collected until the next FullGC. Partial GCs only get the “young” generations. That’s not necessarily the end of the world until you consider that many of the objects contained in the LinkedList might have been very short-lived and might be in the young generation heap. But they can’t be garbage collected because the LinkedList still refers to them. These are known as ‘zombie’ objects–objects that aren’t referred to any more, but never-the-less won’t get collected in a Partial GC.