| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Performance tuning book
Cary,
I detoured from the new Tom Kyte book after chapter 4 to read your test through. chapter 6 of the tom kyte book might have been a better band aid for me at the moment, but - I finally (4 weeks after the issue was raised) got a user to let me know when he was going to run a posting routine. finding someone that would allow me to trace their session, when the client site is 1500 miles away, is the tough part. 40 MB trace file later ...lets say that it will be a huge undertaking to close the loop on that one. can you imagine 10E6 sqlnet roundtrips for a single user in a business day?
The best thing about 10046 trace is, the trace file don't lie and the developer cannot deny. The worst thing is trying to get any changes actually made in the app code.
having an engineering math background with courses in linear algebra, optimizations research - the thing that I picked up the most about your chapter on queueing theory (on the first read, standing between NWK and NYP on NJT) is ...
sensitivity analysis.
It helps if you can think of (mean) response time as an objective function and can view the topology of that surface in a multidimensional space. If you can avoid the steep peaks, the highly non-linear sections, the response times will stay predictable.
an economist or business type that never integrated anyting in the calculus sense would just say "law of diminishing returns" and wouldn't be far off. but the term "marginal" really has no relevance without a derivative.
In chemical engineering distillation, one attempts to avoid a "pinch point" (read: more trays or CPUs won't help) and must avoid an azeotrope (read: no amount of hardware can get you across - can't get more pure than 95% C2H5OH / 5% H20 - aka grain alcohol).
the part that hit me hardest, was that by managing the service level agreement and the business requirement, by getting that mean response time up to 3.5 seconds instead of 3, by allowing 95% of the queries to complete instead of 99% in the tolerance interval - that a single cpu system could handle the load, where an 8 cpu system might not have. (numbers fudged, my copy of your book is in the office)
maybe grid computing will push the knee out a little further.
knowing where the second derivative (of response time as a function of load) is increasing dramatically would indeed be the most useful info - but how to get load vs response data of high enough quality to provide decent enough resolution to afford such info seems completely out of reach to me. (mathcad and polynomial splines bridged the gap for me back in 95).
that sharp part of the curve past the knee can be so steep, so highly sensitive to additional load - that having such info nearly real-time to curtail additional (incoming) load would be a very powerful selling point. some stop lights on the on-ramps could really help.
I hope that the math doesn't scare people off, if you made it through sophmore year of engineering or comp-sci, it should just require scraping the rust off ... but that is only the queueing theory section. The theory does provide extremely interesting results in terms of constraining an optimality condition. If one can eliminate all that is not possible (e.g. square roots of negative numbers) and can estimate what is theoretically possible, one can determine what a reasonable solution would be much more quickly and confidently.
I'm sure that the discussion could have been much more in depth, more theoretical. Heck, you didn't even break out the semi-log or log-log plots! I am planning on following through on some of the recommended texts.
at its price point, there is no excuse for picking it up - and thrusting it at others to read as soon as you're done with it.
thanks for the book.
Paul Drake
Cary Millsap <cary.millsap_at_hotsos.com> wrote: Ryan,
Your two questions have different answers.
I studied mathematics as an undergrad. I focused on the abstract stuff: predicate calculus, language theory, functional analysis, topology, .... In my studies I constructed many, Many, MANY proofs. (A "proof" in mathematics is a piece of technical documentation in which loopholes are impermissible.) I never heard of queueing theory until I had to figure out how to predict performance at an Oracle project I was leading in 1994.
It might be a fun indulgence to say that to be a good Oracle performance
analyst, you have to model yourself after me, but it's just not true.
The honest answer is that many of the best performance analysts I've
ever met have backgrounds that are all over the map: History, Theology,
Economics, Geology, Music, .... Some of the great ones do have a
Mathematics background (Jonathan Lewis, for example), but accusations
that you must have a CS, EE, or Math degree to be a performance analyst
(or to understand "Optimizing Oracle Performance") are patently absurd.
I've written about what I think are the most important traits for the performance analyst in Chapter 1 of the book. This chapter is the one that's available for free at www.oreilly.com. I think relevance, common sense, self-confidence, and the ability to communicate effectively are much more important (and actually more difficult to learn) than a lot of the more obvious educational factors.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
(like subscribing).
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Paul Drake INET: discgolfdba_at_yahoo.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-LReceived on Wed Oct 22 2003 - 02:54:26 CDT
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
 |
 |