| |
|
|
|
|
|
|
|
|
Wednesday, May 28th 2008 |
|
|
|
|
|
8:30 AM - 9:00 AM |
|
Check In |
|
|
|
|
Check In and Complimentary Breakfast |
|
|
|
|
|
|
|
|
|
9:00 AM - 4:30 PM |
|
Seminar Session |
|
|
|
|
Why You Can't See Your Real Performance Problems [morning]AbstractReflecting across nearly 20 years of solving Oracle performance problems, I can recognize a single pattern of behavior that is the dominant reason for failure in all the projects I've witnessed. In almost every case I've seen, failures in diagnosing and repairing performance problems have been caused by unrecognized skew in diagnostic data. This presentation shows several examples that illustrate why skew is such a pervasive problem for performance analysts.Benefits (Key Points)The tools you use to diagnose and repair performance problems have blind spots. This presentation examines those blind spots, shows how to affect project after project, and it discusses what you can do to fix the problem.Measure Once, Cut Twice (No, Really) [afternoon]Abstract"Measure Twice, Cut Once" is a reminder that careful planning yields better gratification than going too quickly into operations that can't be undone. Sometimes, however, it's better to Measure Once, Cut Twice. It's one of the secrets behind how carpenters hang square cabinets in not-so-square kitchens. And it's one of the secrets behind how developers write applications that are easy to fix when they cause performance problems in production use. The key is to know which details you can plan for directly, and which details you simply can't know and therefore have to defend yourself against. In this session, I'll discuss some aspects of software development where flexible design is more important than detailed planning, using woodworking analogies for inspiration. I'll describe some particular flexibilities that your software needs, and I'll describe how to create them.Benefits (Key Points)Some aspects of your design just can't be known at compile time, but you're going to be held accountable for them at operational runtime anyway. For example, "How fast will your code run?" "How much load will your code exert upon the system?" This presentation will help teach you how to build performance problem defense mechanisms into your code. |
|
|
|
|
|
|
|
|
View all Seminars |
