EVTK can be downloaded as a plug-in to the IBM Support Assistant. Download ISA first, and then choose EVTK from the list of available tools. Both are free.
An EVTK forum is available on developerWorks. The forum is pretty quiet at the moment but it has links to installation instructions for EVTK. It would also be great to have more traffic on the forum itself.
EDIT: EVTK has has a name change! It's now known as IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer. Different name, same tool.
Monday, 17 September 2007
Sunday, 16 September 2007
I've just got back from speaking at JavaZone in Oslo. I'll post links to the presentation videos when they're available. The feedback on my presentation and on the Extensible Verbose Toolkit gc analysis tooling I demonstrated was really positive, which was nice.
One of the main things I discussed in my talk is that care is required in interpreting garbage collection pauses. Even though pauses stop an application doing work, which is obviously bad, there's not necessarily any correlation between shorter garbage collection pauses and better application performance. Sometimes shorter pauses give better performance, sometimes longer pauses give better performance. This is pretty uncontroversial if the quality of service requirement is better throughput. It's a lot more contentious if response times are the critical performance metric. After my talk a few people told me about their applications, for which longer garbage collection pauses definitely meant longer response times and definitely mattered a lot. I certainly wasn't going to tell them they were wrong, either! I think the number of cases where there's a strong correlation between garbage collection pause times and response times - or, at least, maximum response times - is pretty high. What I was trying to get across is that there are also at least some cases where the gc pause times are only a small contributor to the maximum response times. It would be unfortunate to minimise pause times without ever checking back against response times if your application happened to be one of the ones where pause times aren't so important.
The whole subject of performance tuning is fascinating because there are so many different system configurations and so many different performance requirements that coming up with a single answer is impossible. Even coming up with a single coherent set of heuristics is pretty tricky.
One of the main things I discussed in my talk is that care is required in interpreting garbage collection pauses. Even though pauses stop an application doing work, which is obviously bad, there's not necessarily any correlation between shorter garbage collection pauses and better application performance. Sometimes shorter pauses give better performance, sometimes longer pauses give better performance. This is pretty uncontroversial if the quality of service requirement is better throughput. It's a lot more contentious if response times are the critical performance metric. After my talk a few people told me about their applications, for which longer garbage collection pauses definitely meant longer response times and definitely mattered a lot. I certainly wasn't going to tell them they were wrong, either! I think the number of cases where there's a strong correlation between garbage collection pause times and response times - or, at least, maximum response times - is pretty high. What I was trying to get across is that there are also at least some cases where the gc pause times are only a small contributor to the maximum response times. It would be unfortunate to minimise pause times without ever checking back against response times if your application happened to be one of the ones where pause times aren't so important.
The whole subject of performance tuning is fascinating because there are so many different system configurations and so many different performance requirements that coming up with a single answer is impossible. Even coming up with a single coherent set of heuristics is pretty tricky.
Subscribe to:
Posts (Atom)