The Most Important Things You Should Know about Oracle®

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

“
@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
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 design
up front
Too many factors conspire to prevent
you from understanding the
performance impact of your design
decisions.

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

@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 Disaster
The 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.
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.
14@CaryMillsap

@CaryMillsap
Expertise in version x
does 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 this
just makes it worse.
Now what?
16

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

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.

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

@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 design
up front
Incremental
design

@CaryMillsap 30
How to structurally ensure feedback failure:
Operators
Operators
Operators
Developers
Architects
...
...
...
...
...
...
h p://carymillsap.blogspot.com/2012/06/organizational-constraint-that.html

@CaryMillsap 31
Understanding the importance of
feedback changes two things:
1. How you hire
2. How you plan

@CaryMillsap 32
nullius in verba
2015C
A
I H8 XPERTSI H8 XPERTS

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

@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
perceived
quality
time
35
The failed project that feels
OK until it dies Go-Live week

@CaryMillsap 36
...So you can
improve your reality.
perceived
quality
time
Tests recalibrate your
perception of quality.

@CaryMillsap 37
If testing is a phase
of your project, then
you’re doing it wrong.

@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.
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 ﬁrst “No”?
40

@CaryMillsap
conﬁrmation bias
noun
the tendency to interpret new
evidence as conﬁrmation of one’s
existing beliefs or theories
41

@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
when would you rather know?
a) never
b) later
c) now
47

@CaryMillsap
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 you
tested your system.
52

@CaryMillsap
Performance is important.
54

@CaryMillsap
Challenge
Your system must have enough capacity
to 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
workload
defined by
your code
defined by
your users

@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

@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
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
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
@CaryMillsap
carymillsap.blogspot.com

The Most Important Things You Should Know about Oracle®

Recommended

Recommended

More Related Content

Similar to The Most Important Things You Should Know about Oracle®

Similar to The Most Important Things You Should Know about Oracle® (20)

More from Cary Millsap

More from Cary Millsap (9)

Recently uploaded

Recently uploaded (20)

The Most Important Things You Should Know about Oracle®