The Most Important Things You Should Know about Oracle®


Published on

I've been around hundreds of Oracle performance projects since 1989, and my colleagues have been around thousands more. In candid after-work talks about our experiences, there has been remarkable symmetry in what we believe makes a project successful. People everywhere seem to be discovering the same secret on their own, through the Agile, Lean Startup, and Design Thinking movements. The secret? Shorter feedback loops. But shortening your feedback loops in Oracle projects is easier said than done. It all depends on how well you Test and Measure. But how do you overcome the political and technical barriers to making great testing and measuring a part of your project plan?

Published in: Software

The Most Important Things You Should Know about Oracle®

  1. 1. The Most Impo ant Things You Should Know about Oracle 1 Cary Millsap @CaryMillsap Oak Table World 2016 11:00a–12:00m Monday 19 September 2016 © 2015, 2016 Cary Millsap
  2. 2. “ @CaryMillsap Most performance problems are 90% political and 10% technical. —Anjo Kolk 2
  3. 3. @CaryMillsap The most important things you should know about Oracle Improve how you test Improve what you measure 3
  4. 4. @CaryMillsap Testing 4
  5. 5. @CaryMillsap You don’t know how your new application is going to perform. Nobody does. Until you measure it. There is no shame in admitting this. 5
  6. 6. “ @CaryMillsap The universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail. —Donald Knuth 6
  7. 7. @CaryMillsap I routinely see on project teams who are expected to design a complex system up front. 7 TOO MUCHPRESSURE
  8. 8. @CaryMillsap 8 Big design up front Too many factors conspire to prevent you from understanding the performance impact of your design decisions.
  9. 9. @CaryMillsap workload source code data distribution storage network database application operating system call count ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Minuscule changes in any of these changes everything: 9 Great examples: Oracle’s RWP video series.
  10. 10. @CaryMillsap 10
  12. 12. @CaryMillsap 12@CaryMillsap Approximately 13 minutes after takeoff from London's Heathrow Airport, on a flight planned to Belfast, Ireland, the outer portion of a fan blade on the #1 engine failed as the airplane was climbing through 28,000 feet. The fan blade failure resulted in high levels of airframe vibration, a series of compressor stalls in the left engine, fluctuation of the left engine parameters, and smoke and fumes in the flight deck. The flight crew, believing that the right engine had failed, reduced thrust on that engine, and subsequently shut it down. The airframe vibration ceased as soon as thrust was reduced on the right engine, reinforcing the crew's identification as the right engine having been the engine that had failed. The crew initiated a diversion to East Midlands Airport, which progressed normally until, at 2.4 nautical miles from the runway, a fire warning and abrupt thrust loss occurred on the left engine. Attempts to restart the right engine were unsuccessful, and the airplane crashed approximately one-half mile short of the airport. Source:
  13. 13. @CaryMillsap 39 passengers died in the accident, and 8 others died later due to their injuries. Of the other 79 occupants, 74 suffered serious injury. The primary event in the accident sequence was the flight crew's misidentification of the #2 engine as the failed engine, and its subsequent shutdown. Source: 13@CaryMillsap
  14. 14. @CaryMillsap After the accident, [the commander] stated that he had judged the #2 engine to be at fault from his knowledge of the aircraft air conditioning system. His reasoning was that he thought the smoke and fumes were coming forward from the passenger cabin; the air for the cabin came mostly from the #2 engine; therefore the trouble lay in that engine. Whilst this reasoning might have applied fairly well to other [Boeing 737-300] aircraft he had flown, it was flawed in this case because some of the conditioning air for the passenger cabin of the Boeing 737-400 comes from the #1 engine. Source: 14@CaryMillsap
  15. 15. @CaryMillsap Expertise in version x does not imply expertise in version x + 1. 15
  16. 16. @CaryMillsap Brief recap: There are important facts about the future of your project that you cannot know right now. Not understanding this just makes it worse. Now what? 16
  17. 17. @CaryMillsap 17
  19. 19. @CaryMillsap 19h p://spo -co on-schaub.html@CaryMillsap
  20. 20. @CaryMillsap 20h p:// At the dawn of the 20th century, radium was America’s favorite new miracle ingredient. Radium-based household commercial products had become the norm, from cold remedies and toothpaste to wool for babies, children’s toys, and even drinking water.
  21. 21. @CaryMillsap 21h p:// The Radium Girls were small-town girls from New  Jersey who had been hired by a local factory to paint the clock faces of luminous watches. ...They painted 250 dials a day, licking their brushes every few strokes with their lips and tongue to give them a fine point.
  22. 22. @CaryMillsap 22h p:// ...By 1927, more than 50 of those women had died as a direct result of radium paint poisoning that was eating their bones from the inside.
  23. 23. @CaryMillsap 23h p://spo -co on-schaub.html@CaryMillsap If only it had burned when they touched it…
  24. 24. @CaryMillsap 24 Imagine if it took 300+ days to discover that you had designed a problem into your system...
  25. 25. @CaryMillsap ...It happens all the time. 25
  26. 26. @CaryMillsap 26 Requirements Design Code Development test Acceptance test Operation 0 50 100 150 200 Phase in which error was detected and corrected Relativecosttofixerror Boehm, B. 1981. Software Engineering Economics. Englewood Cliffs NJ: Prentice-Hall 20× ...And it is expensive.
  27. 27. @CaryMillsap feedback 27 The solution is, first: shorter loops.
  28. 28. @CaryMillsap feedback 28 And second: create tests that give about the riskiest parts of your project first.
  29. 29. @CaryMillsap 29 Big design up front Incremental design
  30. 30. @CaryMillsap 30 How to structurally ensure feedback failure: Operators Operators Operators Developers Architects ... ... ... ... ... ... h p://
  31. 31. @CaryMillsap 31 Understanding the importance of feedback changes two things: 1. How you hire 2. How you plan
  32. 32. @CaryMillsap 32 nullius in verba 2015C A I H8 XPERTSI H8 XPERTS
  33. 33. @CaryMillsap When you hire, find people who know how to test, measure, learn, and prioritize. Not people who claim to already know everything. 33 Changing how you hire...
  34. 34. @CaryMillsap Plan to test continually, and leave time to redo parts of your project in response to what you learn from the tests. 34 Changing how you plan...
  35. 35. @CaryMillsap perceived quality time 35 The failed project that feels OK until it dies Go-Live week
  36. 36. @CaryMillsap 36 ...So you can improve your reality. perceived quality time Tests recalibrate your perception of quality.
  37. 37. @CaryMillsap 37 If testing is a phase of your project, then you’re doing it wrong.
  38. 38. @CaryMillsap 38
  39. 39. @CaryMillsap I’ve chosen a rule that some sequences of four numbers obey, and some do not. Your job is to guess what the rule is. 1. You’ll suggest the next number in the following sequence. 2. I’ll tell you whether the resulting sequence follows the rule. 3. When you have enough information, say "I wish to guess." 4. And then guess the rule. 39 2, 4, 6, __
  40. 40. @CaryMillsap Why did you start guessing the rule before getting your first “No”? 40
  41. 41. @CaryMillsap confirmation bias noun the tendency to interpret new evidence as confirmation of one’s existing beliefs or theories 41
  42. 42. @CaryMillsap 42@CaryMillsap
  43. 43. @CaryMillsap Testing is not “confirmation.” You know, that step where you show that what you did actually works... 43
  44. 44. @CaryMillsap BUT WE CAN'T RUN A TEST THAT might make the TEAM LOOK WEAK. 44
  45. 45. @CaryMillsap New tool: ”destined to fail” 45
  46. 46. @CaryMillsap If your project is destined to fail, when would you rather know? a) never b) later c) now 46
  47. 47. @CaryMillsap If your project is destined to fail, when would you rather know? a) never b) later c) now 47
  48. 48. @CaryMillsap If your project is destined to fail, you need to know now. That doesn’t mean you want it to fail. It means you want to know the truth. 48
  49. 49. @CaryMillsap ou should be glad that bridge collapsed. I was planning to build a dozen more to the same design. —I. K. Brunel 49 Y
  50. 50. @CaryMillsap A failed test is bad news only if you didn’t plan enough time in your project. 50
  51. 51. @CaryMillsap Testing is where you try as hard as you can to break your project. Because if your project is destined to fail, when would you rather know? Now? Later? In production? 51
  52. 52. @CaryMillsap When really smart people demonstrate that the only way they can break your system is by hitting it harder than anybody will need to hit it in production, ... That is when you have you tested your system. 52
  53. 53. @CaryMillsap Measuring 53
  54. 54. @CaryMillsap Performance is important. 54
  55. 55. @CaryMillsap Challenge Your system must have enough capacity to handle the workload you ask it to process. 55 work time capacity workload
  56. 56. @CaryMillsap You know how to control capacity... 56 work time capacity workload
  57. 57. @CaryMillsap Don’t forget: you can also control workload. 57 work time capacity workload
  58. 58. @CaryMillsap 58 workload defined by your code defined by your users
  59. 59. @CaryMillsap 59 response time = call count × call latency how your code is written how often people run it dependson your hardware your call count depends on
  60. 60. @CaryMillsap 60 d = cμ is not a line, because μ = f (c).
  61. 61. “ @CaryMillsap The First Rule of Program Optimization: Don’t do it. The Second Rule of Program Optimization (for experts only!): Don’t do it yet. — Michael A. Jackson 61
  62. 62. @CaryMillsap 62
  63. 63. @CaryMillsap Keep your call counts small. Embed this philosophy everywhere in your system. business processes · architecture · user interface · data · code · everywhere 63
  64. 64. @CaryMillsap Measure your call counts. Embed this philosophy everywhere in your system. business processes · architecture · user interface · data · code · everywhere 64
  65. 65. @CaryMillsap Replace call with click, repeat. #ux #protip 65
  66. 66. @CaryMillsap Call counts are sacred. Measure them. Give your people time to eliminate unnecessary calls, at every phase of your project. 66
  67. 67. @CaryMillsap Recap 67
  68. 68. “ @CaryMillsap Most performance problems are 90% political and 10% technical. —Anjo Kolk 68
  69. 69. @CaryMillsap Is your goal to have an awesome system? Or to save face? ...Not deciding is also a decision. 69 The 90% political part
  70. 70. @CaryMillsap Eliminate calls (code path). Shorten feedback loops. Create feedback continually with adversarial tests. Plan these tasks into your project. 70 The 10% technical part
  71. 71. @CaryMillsap Thank you 71 @CaryMillsap