Xref: utzoo comp.arch:4686 comp.databases:978
Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!amdahl!rtech!davek
From: davek@rtech.UUCP (Dave Kellogg)
Newsgroups: comp.arch,comp.databases
Subject: Re: Unix machines for large databases
Message-ID: <2064@rtech.UUCP>
Date: 7 May 88 08:09:54 GMT
References: <22126@pyramid.pyramid.com>
Reply-To: davek@rtech.UUCP (Dave Kellogg)
Organization: Relational Technology Inc, Alameda CA
Lines: 74
Keywords: INGRES, RTI, TP1, DebitCredit


I can understand Eric's skepticism because if someone told me 6 months
ago that INGRES would exceed 100 TPS I might have asked them if they 
bumped their head on the way to the office.

However, I know what Mark Diamond says is true because I was in the room
with him, along with Tom Sawyer from Codd & Date consulting, when INGRES 
hit 104 TPS.

To appease any cynics I'll list the one caveat of the benchmark first:

	* The INGRES system (running on a Sequent Symmetry machine) which
	  hit 104 TPS was running a prototype version of RTI's next release.
	  As part of normal prototyping activity we asked ourselves "Just
	  how fast can this go?"  We convinced Sequent to let RTI use a
	  large Symmetry machine, and we were off...


Eric was surprised about the 1+ Gigabyte database size.  In fact, the 
benchmark was run with a DebitCredit defined 100 TPS sized database.  Before
continuing, a little background on the DebitCredit benchmark is in order.

DebitCredit is a well-defined standard benchmark and was written in the 
late 1970's  by Jim Gray and about 20 other database professionals.  The 
paper was eventually published in DATAMATION under the title "A Measure of 
Transaction Processing" by the authors "Anon et al."  Rumour has it the 
authors wished to remain secret due to flame-ups that occurred after Dave 
DeWitt and Dina Bitton wrote their paper on DBMS benchmarking.

DebitCredit is one of three benchmarks described in the paper, and various
degenerate forms of DebitCredit  have become loosely known in the industry
as "TP1."  The problem with TP1, and the ensuing "TPS" (transactions/second)
measurements, is that most vendors size the databse irregularly (i.e. smaller
than DebitCredit defines).  Thus, as Eric points out, when comparing TPS 
measurements one is often comparing apples and oranges.

For the Silver Bullet benchmarks, to which Mark refers, the database was
sized at 100 TPS, or 10 Million 100 byte account records, 10,000 100 byte
teller records, and 1,000 100 byte account records.  Thus, a real purist
would rob RTI of the 104 TPS (and grant only 100 TPS) because the database 
was sized for 100 TPS.  (If you do the multiplication you'll see that
the account relation alone is 1 gigabyte of data.)

Overall, the benchmark conformed to DebitCredit standards quite well, 
including the submission of tranasctions via a network.  However, there
were a few things we didn't do 100% to the DebitCredit spec.  But then
again, we did a couple to exceed the spec.  In any case, the auditor's 
report is being published tommorrow so all DebitCredit whizzes can take
a look.

In conclusion, I saw one "pop-off" on the net (flame semi-on) which questioned
the integrity of the auditor since "Codd and Date and RTI have always had 
a good working relationship..." I'll reply to that with

	* If we wanted to pay someone to lie we wouldn't have paid
	  Codd and Date's rates!  ;-)

	* Mr. Sawyer was the auditor of Tandem's 208 TPS benchmark.

	* I personally hope that he is not on the net to see this random
	  assault on his character.

	* If you read his report you'll see that he is certainly impartial.



Finally, if you're interested in seeing the benchmark report you can reply
to this message with a postal address and I'll do my best to get you a copy.


Dave Kellogg
ucbvax!rtech!davek (might need a mtxinu before the rtech)


"Hmmm.  We hit 100 TPS, can I go to bed now??"