[intro music]
[theme music]
Hi. I'm Andrew Holdsworth.
I'm the Vice President of Real World Performance within the database
development group
here at Oracle. I've been running the
Real World Performance group for nearly twenty years
and we are quite a large team, and really, we're focused on
improving the performance of Oracle
database in the real world.
Which is very often a complicated subject in itself
and because what really what we're interested in
is seeing people using our products better
and going orders of magnitude faster. And this is very much our target
when my team engages in things, is to make things ten times faster
a hundred times faster, even a thousand times faster.
Now, this is quite an ambitious target
very often people will say "oh, we will just be happy if it was twice as fast!"
but in many respect this is not interesting.
If we were wanting to speed up things by 2x we could just wait 18 months and let
Moore's Law do the
work for us. And so, with that in mind
we're always looking to get ahead of Moore's Law and to do better,
and really in terms of real-world performance
it's a case of getting ahead of Moore's Law and being smarter in
how we are using the database. Now, one of the unfortunate things about the Oracle
databases is that
in the real world, it's not used that well. In fact it is
not being used optimally well at all.
And with this in mind, what the Real World Performance group is actually in
the last few years has put
a large amount of investment in education techniques
to try and get people to get their money's worth
out of the database.You spend a lot of money on hardware, you spend a lot of
money on
software licenses, and in many cases it's
it's very unfortunate the lack of
success people have for their investment. And so what we are
putting into focus is to try and teach people how to use the product
better.
And when people start using the product better, things run faster they become
more available, they become more predictable,
almost boring and less exciting. And
in the IT industry they say we're all boring and nerds, but in fact we
actually create far too much excitement for ourselves.
In fact we make it way too exciting and exciting to me means lost weekends
working all night, and that's not my idea
have fun. I like to use my weekends
something else. So with that in mind,
let's start thinking about real world performance and the challenges that
we see without even going into technical specifics. Now one of the first things we
really notice
is in many cases the product is used
incorrectly, okay? This may be a legacy
of not upgrading how you use the product through the versions so the
product is configured like it was done in version 6 or
version 7, but now you're running version 11
and you're carrying a legacy of those old parameters,
settings, techniques, ideas through to working with version 11 and eventually 12.
Now let's think about what happened between version 6 and 7, and 11 and 12.
Look at what happened to the CPU speeds. The scaleability of multiple
CPU, multiple core machines. Let's look at the size of the memory
and the size of the i/o systems. Every thing got
bigger by orders of magnitude. Now in any engineering discipline when things
get bigger by orders of magnitude
something has to change and something has to evolve.
And that thing that usually needs to evolve is the application code in logic
in the algorithms,
We've also been dealing with the fact that data set have been increasing by in
in fact
orders of magnitude greater than Moore's Law, and so
this brings me, and segments me, to the next challenge that we really see
in real world performance. In many cases
there is code and logic and techniques being applied to it
information problem akin to a what we would call a small data problem for
dealing for the 100 rows or
10 rows or handful of rows and they're trying to apply those techniques and
those algorithms to something that might have
a million rows or billion rows or sometimes even a trillion rows.
Now, you cannot--you can see very quickly
this is a big problem in itself.
Just imagine if you had a small transactions that took
a millisecond, okay? If you had to do
a thousand those in a sec, it would take
one second. We start expanding that and say
okay we came from a thousand to a million, you can see
that would take a thousand seconds nearly twenty minutes.
If we would take that to the next level and take it even further along,
and take it up to a trillion rows, the time to take to a trillion transactions
each executing within a millisecond which may sound fantastic to a developer,
would be 32 years. So, with that in mind,
we've got to work at it. Understanding that we have to adapt our
algorithms and techniques as the datasets increase
and the types of hardware, and performance of the hardware, and the
software algorithms associate with this.
And this is really what real world performance has become...
learning to recognize are we using the wrong product
the wrong techniques and the wrong algorithms be it either
inside the database or inside the application logic
because this is where the order of magnitude gains come along.
The other problem we've also face with in database performance
is that if you have noticed and I'm sure we've all look to LinkedIn once in a
while
anybody who claims to be an Oracle expert has tagged performance as their expertise
however so there's millions of Oracle experts so there's millions a
performance experts,
but this isn't really true. The real reality is that somebody somebody once in
their career has fiddled with something
and made things go faster. That they understand why it went faster,
probably not, but they fiddled with it, they took the credit for it,
had success with it, and so suddenly they became a newly minted performance expert
without really quite understanding the problem. So
with this in mind we also see that people's tuning techniques
consists of just literally trying and fiddling and playing with parameters and
settings
and hoping things will get better, okay.
In many cases people are jumping into the solution space
without really understanding the problem. This is called 'hacking' in our industry.
You know we just fiddle and fiddle and hoping things get better without really
understanding the problem.
Now one of the things we really teach with my engineers is if they can't articulate the
problem
they better not propose a solution. They better go back
work all night or whatever it takes, until they understand what the problem is
because usually when you can articulate the problem the solution is easy.
And so one of the challenges for all Real World Performance engineers, is
figuring out what the problem is. If you can't figure out what the problem is
you better not make a suggestion. And these gets to something else that we
also see
is that people sound very eloquent in meetings and sound like they understand
what's going on in making lots of
intelligent sounding suggestions, but we should not be jumping into solution
space
until we understand the problem. One of my other engineers
also calls this activity something else, is confusing
activity with progress. You know we can do a lot a busy work pretending to move
the needle,
but until you really move the needle of performance
an order of magnitude, two orders of magnitude, three orders of magnitude,
you actually haven't done real world performance. And if you can
plan an engineer to make things a thousand times faster because you
understand the problem,
you become a very valuable, useful real-world performance engineer.