The Most Impo!ant Things You Should Know about Oracle

1

Cary Millsap

@CaryMillsap

Oak Table World 201611:00a–12:00m Monday 19 September 2016

© 2015, 2016 Cary Millsap

“@CaryMillsap

Most performance problems are 90% political and 10% technical.

—Anjo Kolk

2

@CaryMillsap

The most important things you should know about Oracle

Improve how you test

Improve what you measure

3

@CaryMillsap

Testing

4

@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

“@CaryMillsap

The universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.

—Donald Knuth

6

@CaryMillsap

I routinely see

on project teams who are expected to design a complex system up front.

7

TOO MUCHPRESSURE

@CaryMillsap 8

Big designup front

Too many factors conspire to prevent you from understanding the

performance impact of your design decisions.

@CaryMillsap

workloadsource codedata distributionstoragenetworkdatabaseapplicationoperating systemcall count

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Minuscule changes in any of these changes everything:

9

Great examples: Oracle’s RWP video series.

@CaryMillsap 10

@CaryMillsap 11

A STORY BY LessonsLearned.FAA.gov

ECO15 PRESENTS A METHOD R PRODUCTION

“THE KEGWORTH AIR DISASTER: THE TRAGIC STORY OF BRITISH MIDLAND FLIGHT 92” TOLD BY CARY MILLSAP

The Kegworth Air DisasterThe Tragic Story of British Midland Flight 92

@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: LessonsLearned.FAA.gov

@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: LessonsLearned.FAA.gov

13@CaryMillsap http://lessonslearned.faa.gov/ll_main.cfm?TabID=3&LLID=62&LLTypeID=2#null

@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: LessonsLearned.FAA.gov

14@CaryMillsap

@CaryMillsap

Expertise in version xdoes not imply

expertise in version x + 1.

15

@CaryMillsap

Brief recap:

There are important facts about the future of your project that you

cannot know right now.

Not understanding thisjust makes it worse.

Now what?

16

@CaryMillsap 17

@CaryMillsap 18

A STORY BY CARY MILLSAP

ECO15 PRESENTS A METHOD R PRODUCTION

“LONG FEEDBACK LOOPS KILL” TOLD BY CARY MILLSAP WRITTEN BY CARY MILLSAP

© 2015 CARY MILLSAP

Long Feedback Loops KILL

@CaryMillsap 19h"p://spo!squee.blogspot.com/2007/03/today-on-hot-stove-ma"-co"on-schaub.html@CaryMillsap

@CaryMillsap 20h"p://www.messynessychic.com/2015/07/02/the-radium-girls-and-the-generation-that-brushed-its-teeth-with-radioactive-toothepaste/

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.

@CaryMillsap 21h"p://www.messynessychic.com/2015/07/02/the-radium-girls-and-the-generation-that-brushed-its-teeth-with-radioactive-toothepaste/

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.

@CaryMillsap 22h"p://www.messynessychic.com/2015/07/02/the-radium-girls-and-the-generation-that-brushed-its-teeth-with-radioactive-toothepaste/

...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.

@CaryMillsap 23h"p://spo!squee.blogspot.com/2007/03/today-on-hot-stove-ma"-co"on-schaub.html@CaryMillsap

If only it had burned when they touched it…

@CaryMillsap 24

Imagine if it took 300+ days to discover that you had designed a

problem into your system...

@CaryMillsap

...It happens all the time.

25

@CaryMillsap 26

Requirements Design Code Developmenttest

Acceptancetest

Operation0

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.

@CaryMillsap

feedback

27

The solution is, first: shorter

loops.

@CaryMillsap

feedback

28

And second: create tests that give

about the riskiest parts of your project first.

@CaryMillsap 29

Big designup front

Incremental design

@CaryMillsap 30

How to structurally ensure feedback failure:

Operators

Operators

Operators

DevelopersArchitects

...

...

...

...

...

...

h"p://carymillsap.blogspot.com/2012/06/organizational-constraint-that.html

@CaryMillsap 31

Understanding the importance of feedback changes two things:

1. How you hire2. How you plan

@CaryMillsap 32

nullius in verba

2015CA

I H8 XPERTSI H8 XPERTS

@CaryMillsap

When you hire, find peoplewho know how to

test, measure, learn, and prioritize.

Not people who claim to already know everything.

33

Changing how you hire...

@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...

@CaryMillsap

perceivedquality

time

35

The failed project that feels OK until it dies Go-Live week

@CaryMillsap 36

...So you can improve your reality. perceived

quality

timeTests recalibrate your perception of quality.

@CaryMillsap 37

If testing is a phaseof your project, then

you’re doing it wrong.

@CaryMillsap 38

@CaryMillsap

I’ve chosen a rule that some sequencesof 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.

39http://www.nytimes.com/interactive/2015/07/03/upshot/a-quick-puzzle-to-test-your-problem-solving.html

2, 4, 6, __

@CaryMillsap

Why did you start guessing the rule before getting your first “No”?

40

@CaryMillsap

confirmation biasnoun

the tendency to interpret new evidence as confirmation of one’s existing beliefs or theories

41

@CaryMillsap 42@CaryMillsap

@CaryMillsap

Testing is not “confirmation.”You know, that step where you show that what you did actually works...

43

@CaryMillsap

BUT WE CAN'T RUN A TEST THAT might

make the TEAM LOOK WEAK.

44

@CaryMillsap

New tool:

”destined to fail”

45

@CaryMillsap

If your project is destined to fail,when would you rather know?

a) never

b) later

c) now

46

@CaryMillsap

If your project is destined to fail,when would you rather know?

a) never

b) later

c) now

47

@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

@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

@CaryMillsap

A failed test is bad news only if you didn’t plan

enough time in your project.

50

@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

@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 youtested your system.

52

@CaryMillsap

Measuring

53

@CaryMillsap

Performance is important.

54

@CaryMillsap

Challenge

Your system must have enough capacityto handle the workload you ask it to process.

55

work

time

capacity

workload

@CaryMillsap

You know how to control capacity...

56

work

time

capacity

workload

@CaryMillsap

Don’t forget:you can also control workload.

57

work

time

capacity

workload

@CaryMillsap 58

workloaddefined by your code

defined by your users

@CaryMillsap 59

response time = call count × call latency

how your code is writtenhow often people run it

depends on

your hardwareyour call count

depen

ds on

@CaryMillsap 60

d = cμ is not a line, because μ = f (c).

“@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

@CaryMillsap 62

@CaryMillsap

Keep your call counts small.

Embed this philosophy everywhere in your system.

business processes · architecture · user interface · data · code · everywhere

63

@CaryMillsap

Measure your call counts.

Embed this philosophy everywhere in your system.

business processes · architecture · user interface · data · code · everywhere

64

@CaryMillsap

Replace call with click, repeat.

#ux #protip

65

@CaryMillsap

Call counts are sacred.Measure them.

Give your people time to eliminate unnecessary calls, at every phase of

your project.

66

@CaryMillsap

Recap

67

“@CaryMillsap

Most performance problems are 90% political and 10% technical.

—Anjo Kolk

68

@CaryMillsap

Is your goal to have an awesome system?

Or to save face?

...Not deciding is also a decision.

69

The 90% political part

@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

@CaryMillsap

Thank you

71

@CaryMillsapcarymillsap.blogspot.com