Comments on: Book review: Optimizing Oracle Peformance

By: Shlomi Noach

Shlomi Noach — Fri, 08 Jan 2010 04:37:33 +0000

Hi Cary,

100% agree to all of the above

Shlomi

By: Cary Millsap

Cary Millsap — Thu, 07 Jan 2010 19:16:32 +0000

Shlomi,

I agree with your idea that it’s difficult to create an environment in which you’ll foresee all your production problems in advance of actually encountering those problems in production. But I think the following points are important:

…You’ll catch a lot more problems if you try to catch them prior to production than if you don’t even try. I think a lot of people don’t even try because they feel it would be futile to execute any plan that’s provably imperfect from the outset!

…You’ll never catch all your problems in pre-production testing. That’s why you need a reliable and fast method for solving the problems that leak through your pre-production testing processes.

Somewhere in the middle between “no testing” and “full production emulation” is the *right* amount of testing.

My main point about Method R, though, is that *profiling* is an absolutely essential part of the software life cycle: in production, yes, but also long before then, early in the development of the software too. That, in fact, (and this was Knuth’s point) is where profiling is the *most* important.

—Cary

By: Shlomi Noach

Shlomi Noach — Thu, 07 Jan 2010 18:49:48 +0000

Hi Cary,
Many thanks.
Though, even as you suggest, it would be impossible to actually measure the performance of that task which is most important to the customer, since real-life load tests may not be achieved; it is therefore back to estimations, is it not?
But I’m not talking about estimation per se. I’m referring to basic, reasonable table_query design. Of course, that query which only runs twice per day, is not that important. And of course, that query which is used extensively throughout the day should be taken care of. And I see this as the very basic question a consultant should ask the customer.
If I understand correctly your comment, it’s basically the same thing.
Only in preactive mode it cannot be truely measured, so it’s not technically deterministic and correct.

Again, I enjoy reading through your book!

Regards

By: Cary Millsap

Cary Millsap — Thu, 07 Jan 2010 17:38:00 +0000

We’ve been working a lot over the past five years or so on the “reactive vs. preventative” issue. Granted, the book doesn’t really say anything about the subject of problem prevention, so it’s left to the imagination of the reader how to tackle problems in that domain.

But in reality, the only reliable way I know to prevent performance problems is to measure your code prior to going production with it. Doing it any other way—like trying to guess where your code is probably slow—just doesn’t work. It’s the same today as Knuth observed several decades ago.

So, the only step that changes in Method R when you need a preventive context is step 1, the targeting step. We actually list at our Method R web site as “Identify the task that’s the most important to you.” Note the subtle change here from what you see on p20 of the book: “Select the user action for which the business needs improved performance.”

This subtle change makes it easier to see the relevance of Method R in the union of reactive and preventive contexts. For example, the definition of important to you might be…

…a task that’s giving your business a performance problem today. That’s what the book talks about.

…a business-critical task that’s not executing slowly right now, but if it were to slow down, it would damage your business. You need to measure tasks like this periodically and engage your problem repair skills any time you notice a negative trend.

…a task that’s not business-critical, but that has a long run-time. This kind of task is important, not matter what its business priority is, because it has the most potential for getting in the way of everything else.

…a task that consumes a lot of a resource that you’re trying to conserve. Most often in my experience, this resource is CPU, because that’s the most expensive resource in the machine. (A lot of my customers have the biggest, fastest CPUs that humans can make; to upgrade from there, they have to await new inventions, which is an expensive kind of wait, both in time and, ultimately, money.)

…a task that you’re writing today for production use sometime in the future. In this context, Method R is simply measuring to find your “critical code” in the Knuth sense.

—Cary Millsap

By: Shlomi Noach

Shlomi Noach — Thu, 07 Jan 2010 03:50:29 +0000

Hi Daniel,

I’m also now reading the book. I like it, but I want to further support your observation that it is reactive.
I’ve also left notes on Baron’s post: http://www.xaprb.com/blog/2009/12/09/response-time-optimization-in-systems-that-are-queued/, where I try to convey a point discussing with Fernando.

If I understand correctly from my reading so far, method R will not require me to do *anything* if I’m observing a relaxed MySQL machine a customer has asked me to review.
Perhaps I can see 50% of the queries are using full table scans, and queries EXPLAIN says “using join buffer” or other “atrocities”. According to method R, dealing with these is working by “hunch” and is inappropriate.
I disagree. I do not consider this a hunch. IT is a fundamental check up.

When you build a building, you must have the foundations and pillars set up straight. If they’re not, and you only have 2 floors, all me be well. But counting on adding another 20 floors is a different matter.
So even while you have only 2 floors, and all is well, it is proper and important to do what basic fixed would make the foundations stronger.

In a sense, working by Method R only (and again, I’m still reading through the book, I hope I’m not commenting prematurely), is a “recipe for disaster”. The author tells us companies only call up on his hotsos company when all hell breaks loose and they’re in emergency. Method R probably works best then.
But how (if!) will method R work when a customer is intelligent and careful enough to call up on consultant advice while still developing the application? Before it’s even online? To have the consultant share his opinion: “Is this a good design?”. So, sure, load tests and all; but this still leaves territory untouched by Method R.

My 2 cents

Regards

By: Mark Callaghan

Mark Callaghan — Wed, 06 Jan 2010 21:07:34 +0000

MySQL will have something equivalent when the performance schema data described by PeterG can generate a trace of events in timestamp order so we can see where a connection ran and waited while executing a query. And the trace must be done for code above the storage engine and code in the storage engine.

InnoDB/Oracle has yet to comment on whether they will instrument their code.

By: Daniel Nichter

Daniel Nichter — Wed, 06 Jan 2010 20:20:50 +0000

Peter,

That’s excellent! I’ve not been following MySQL 6.0 so this is pleasant news. Keep up the good work. This is going to open a lot of doors for MySQL performance optimization.

By: Peter Gulutzan

Peter Gulutzan — Wed, 06 Jan 2010 19:34:50 +0000

> Does MySQL have anything similar?

We’re on the way. The next version of MySQL
has instrumentation, including timing and
counting, for some mutex and disk input/output.
That’s comparable to certain Oracle Wait Interface
tables.

Blog postings in order of appearance:
http://blogs.mysql.com/peterg/2009/02/05/mysql-performance-schema/
http://blogs.mysql.com/peterg/2009/02/06/mysql-performance-schema-2/
http://blogs.mysql.com/peterg/2009/02/09/mysql-performance-schema-3/
http://blogs.mysql.com/peterg/2009/02/10/mysql-performance-schema-4/
http://blogs.mysql.com/peterg/2009/02/11/mysql-performance-schema-5/
http://blogs.mysql.com/peterg/2009/02/12/mysql-performance-schema-6/
http://blogs.mysql.com/peterg/2009/02/13/todo-mysql-performance-schema-7/