This document discusses the tradeoffs between diagnosability and cloud computing. It notes that while the cloud aims to hide details, performance engineers need visibility into where time is spent to manage performance. It argues that instrumentation is key to diagnosing performance issues by marking tasks so their time can be identified and measured. The Oracle Database provides good tools for instrumentation, but applications also need to be designed to use them. Forethought about instrumentation can save costs and improve performance and availability.

1. Diagnosability
versus
The
Cloud
Cary
Millsap
Method
R
Corporation
cary.millsap@method-­‐r.com
/
@CaryMillsap
OTN
Architect
Day,
Toronto
10:00a–10:30a
Thursday
21
April
2011

2. Cary
Millsap
Teaching Consulting Business Method Software
1985–1987
1988–1989
1990–1992
1993–1995
1996–1999
2000–2003
2004–2008
2009–2010
2011–201x
0 25 50 75 100

3. Q What
does
The
Cloud
mean
to
you?
Somebody
else’s
capital
expenditure.
Somebody
else’s
hardware.
Somebody
else’s
so8ware.
Somebody
else
backs
it
up.
Somebody
else
upgrades
it.
Somebody
else
fixes
it
when
it
breaks.
...

4. Q What
does
Diagnosability
mean
to
you?
You
can
find
problems
efficiently.
You
can
fix
problems
efficiently.

5. What
is
“easy
to
diagnose”?

6. It’s
easy
to
diagnose
when
it’s
easy
to
answer…
Which
system?
Which
program?
...
Which
line
of
source
code?

7. Q How
many
of
you
are
performance
people?
Here’s
how
you
can
tell...

8. Q Do
you
prefer
a
fast
system?
Or
a
slow
system?
Then
you’re
a
performance
person.

9. One
goal
of
The
Cloud
is
to
hide
detail.
But...

10. If
the
details
of
where
time
is
being
spent
are
concealed
from
your
technical
people,
it’s
a
problem.

11. (You
do
still
have
technical
people,
right?)

12. Some
of
diagnosability’s
natural
enemies:
n-­‐tier
architectures
multiplexing
architectures
connection
pooling,
session
pooling,
...
service-­‐X
architectures
X
∈
{bus,
oriented,
…}
The
Cloud

13. http://en.wikipedia.org/wiki/File:ESB.svg

14. SOA
http://en.wikipedia.org/wiki/File:SOA_Metamodel.svg

15. http://en.wikipedia.org/wiki/File:Cloud_computing.svg

16. No
matter
how
your
software
fits
together,
to
manage
performance,
you
must
be
able
to
follow
how
time
flows
through
all
the
code
that
services
your
requests.

17. The
sequence
diagram
helps
you
conceptualize
time
flow...
http://en.wikipedia.org/wiki/File:Restaurant-­‐UML-­‐SEQ.gif

18. The
key
to
accounting
for
time
flow:
Instrumentation

19. Instrumentation
is
code
that
marks
each
task
so
you
can
1.
identify
it
2.
measure
its
time

20. The
Oracle
Database
gets
it
right.
mark...
dbms_session,
dbms_application_info,
OCIAttrSet,
setEndToEndMetrics,
...
measure...
dbms_monitor,
ASH,
AWR,
ADDM,
...
http://www.method-­‐r.com/downloads/doc_details/72-­‐mastering-­‐performance-­‐with-­‐extended-­‐sql-­‐trace

21. Diagnosability
begins
with
the
Oracle
Database’s
superb
tools
for
marking
tasks.

22. My
message…

23. 1 /6
No
matter
how
much
you
test,
you
can’t
know
how
an
application
is
going
to
behave
until
after
you’re
using
it
in
production.

24. 2 /6
You
can
reduce
your
operational
costs
significantly
if
you
can
make
your
application
easy
to
diagnose.

25. 3 /6
The
Oracle
Database
has
superb
diagnostic
hooks
built
in,
but
your
application
has
to
be
designed
to
use
them.

26. 4 /6
If
you’re
using
prepackaged
software,
diagnosability
is
a
feature
on
which
you
need
to
insist.

27. 5 /6
If
you’re
building
your
own
software,
diagnosability
is
not
that
difficult;
it’s
just
another
software
feature.

28. 6 /6
Forethought
and
understanding
about
instrumentation
saves
you
money
and
yields
better
performance
and
availability.

29. Instrumentation
saves
you
money
and
yields
better
performance
and
availability.

30. http://method-­‐r.com
http://carymillsap.blogspot.com
http://twitter.com/CaryMillsap