STPCon 2007: Day Three
October 5, 2007 – 4:43 am9:00 am - 10:00 am: Applying SPE to Java EE Application Design, Development and Deployment
William Louth
If I can try to summarize SPE (Software Performance Engineering) in a single sentence, it is the practice of characterizing application use cases and creating models that can have many uses, including problem diagnosis, and modeling or prediction of performance or resource usage (see www.spe-ed.com for more about SPE). In this session, Louth provided an overview of SPE and how and why it can be used in the performance engineering effort, emphasizing that it should be part of development and engineering, rather than an after-the-fact activity of problem diagnosis. He explained the benefits of using SPE to create software models and system models, that it helps the performance engineer by giving him a more complete understanding of how the software works- an understanding that is normally not possessed by developers or operations personnel.
Louth demonstrated how to get data for software models and system models using the JXInsight tool and identified some of the key data inputs into the models. He provided an example of how the models can be used to diagnose application performance problems.
An hour’s time is hardly adequate to do justice to the subjects of SPE and J2EE performance, but the key takeaway for me was the benefit of understanding how the software works, and answering the question of “what I have learned from this test?” Although I don’t have immediate plans for implementing SPE (as taught by the folks at Performance Engineering Services) at my company, an increased understanding of how the application works will certainly be beneficial.
10:30 am - 11:30 am: Performance Bottlenecks, Part 2: Exploiting Performance Bottlenecks Collaboratively
Scott Barber
The key message from this session was that performance testers and developers need to work together to remove bottlenecks. I didn’t attend Part 1, but the basic idea there was that there is always a bottleneck, and as performance testers we can’t necessarily prove the existence, but we can provide symptoms or evidence, then make changes to determine if the bottleneck has been removed. In Part 2, Barber talked about success factors in bottleneck tuning, especially with regard to the roles of the team: performance testers, developers, managers, etc. This session seemed mostly fluff, with no Eureka! moments or revelations.
1:30 pm - 2:30 pm: Java EE Performance-Tuning Methodology: Wait-Based Tuning
Steven Haines
If I had never heard of “Wait-Based Tuning” and hadn’t already read Steven Haines book, Pro Java5 EE Performance and Tuning, this probably would have been an intriguing class. Unfortunately for me, I was already pretty familiar with the topic, and there wasn’t too much new here, other than a reminder for me that I need to find out how Spring and Hibernate might be caching or pooling beans. I probably should have known this was going to be the case. At least I found out what Steven Haines looks like.
3:00 pm - 4:00 pm: Rooting Out Java EE CPU Performance Bottlenecks
Sreekanth Makam
The title is somewhat of a misnomer. When I think of “CPU Bottleneck”, it means (to me) that the CPU is a resource constraint preventing an application from scaling. In this session, however, Sreekanth Makam provided some methods of identifying why you might NOT be able to use all of the CPU in a server. That is, there are other bottlenecks preventing the full use of CPUs, and he detailed how to detect and diagnose some of the most common reasons. Still, the topic interests me and it was interesting to hear how others try to diagnose performance bottlenecks.
