RE: Comment on 'Practical Oracle 8i'

Before I reply, so far at page 100 I think the book is great. I plan on finishing it this weekend.

Anyway, I agree entirely. I think it really depends. But there are strong reasons in both directions.

One thing that would make that test very difficult is MHz to MHz isn't the same.

For example. 100MHz Pentium is no where near 1/15 the speed of the 1.5GHz AMD. So it remains a very difficult test to make.

I figured since I am so slow to actually buy your book, (which I am now regreting as it is so far very fun read), I assumed it may have already been discussed.

Wondering if I am going to get a "Why would we care to read this" reply message for this too.

<Peers down to his sig quote>

"Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes."

Christopher R. Spence
Oracle DBA
Phone: (978) 322-5744
Fax: (707) 885-2275

Fuelspot
73 Princeton Street
North, Chelmsford 01863  

-----Original Message-----
Sent: Thursday, August 16, 2001 1:13 PM
To: Multiple recipients of list ORACLE-L

I don't know how bookpool does it - it's been at deep discounts since publication, whereas Amazon managed to cut it by 10% for about two weeks in 9 months.

A comment like yours came up on the comp.databases.oracle.server newsgroup very soon after the book came out. The convenient weasel word is of course the 'often'.

I had forgotten when I wrote it that Steve had made exactly the opposite comment;
however, there is room for both of us to be correct. The effect is application-dependent.

Cary Millsap has an article on his website www.hotsos.com which describes a case
where upgrading the CPUs to a higher
speed (same number) resulted in the OLTP users complaining about a drop in performance.

The bottom line is that queuing theory always kicks in when you have a small number of resources and a large number of users.
The effect can be exaggerated when the
unit of resource offered is significantly larger than the amount of resource that many of the users can take advantage of. This,
of course is the argument in the second
part of your note.

Of course, it would be rather nice to be able to set up an entire environment
with a high-stress application, and
then run a test which kept the total
available MHz constant but changed
the number of chips. But even then
you'd have to be very careful about what it was you were actually measuring.

Any volunteers with a couple of
megabuck's of hardware and
a few weeks of HR to spare ?
(Preferably in an interesting part
of the world, and I'd supervise
the tests).

Jonathan Lewis

Seminars on getting the best out of Oracle Last few places available for Sept 10th/11th See http://www.jlcomp.demon.co.uk/seminar.html

-----Original Message-----
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Date: 16 August 2001 06:04

|Must say BookPool.com is so awesome. 40% off most books (which I
bought
|three this time) and paid $4 for 5 day shipping yet I get it the next
day on
|my doorstep. Got to love that.
|
|Page 28:
|
|I will quote:
|
|"A greater number of slower CPU's is often better than a fewer number
of
|faster ones."
|
|
|To some extent I believe this is true especially with the efficient
use of
|caching in most OS's. But with the larger caches on unix cpu's, 4Mb,
8Mb.
|There is a loss of performance when a process runs on a cpu, then
context
|switches and then placed on another cpu. All the cached tlb's are
then
|sitting on another cpu and need to be reloaded. Although the os will
try to
|reschedule recently run processes on the same cpu, that doesn't
always
|happen on a busy system. Also the fact that faster cpu's return the
|processes back faster.
|
|Although on the other hand, with more cpu's, more can get done
|simultaneously but at a slower rate. And there would be fewer
context
|switches with many more cpu's.
|
|Just something to think about.
|--
|Please see the official ORACLE-L FAQ: http://www.orafaq.com
|--
|Author: Christopher Spence
| INET: cspence_at_FuelSpot.com
|
|Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
|San Diego, California -- Public Internet access / Mailing
Lists
|--------------------------------------------------------------------
|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-L (or the name of
|mailing list you want to be removed from). You may also send the HELP
|command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jonathan Lewis
  INET: jonathan_at_jlcomp.demon.co.uk

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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-L (or the name of
mailing list you want to be removed from).  You may also send the HELP
command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Christopher Spence
  INET: cspence_at_FuelSpot.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).