[comp.databases] Database benchmarks - debit/credit and TP1

paul@cantuar.UUCP (Paul Ashton) (01/20/89)

I have been asked if I can get some information on database benchmarks
that vendors often publish results for.  The debit/credit and TP1
benchmarks are ones I am aware of, but have little information on.
If people can give me references to specifications on how to construct
and run these benchmarks I would appreciate it.

Please respond by email, I will post a summary.

Thanks, Paul Ashton

-- 
Internet(ish):  paul@cantuar.{uucp,nz}  JANET/SPEARNET: p.ashton@nz.ac.canty
UUCP:              ...!{watmath,munnari,mcvax,...!uunet!vuwcomp}!cantuar!paul
NZ Telecom:     Office: +64 3 667 001 x6350
NZ Post:        University of Canterbury, Christchurch, New Zealand

jon@altos86.UUCP (Jonathan Ma) (01/24/89)

In article <880@cantuar.UUCP>, paul@cantuar.UUCP (Paul  Ashton) writes:
> I have been asked if I can get some information on database benchmarks
> that vendors often publish results for.  The debit/credit and TP1
> benchmarks are ones I am aware of, but have little information on.
    Benchmark programs are generally available from the database vendors.
	I got mine from both Informix (Credit/Debt) and Unify (TP1).  They
	are very useful and easy to use too.  We are using TP1 to benchmark
	our hardware and application software.

	-Jon-		Jonathan Ma, Altos Computer Systems
				UUCP: {pyramid,sun}!altos86!jon

davek@rtech.rtech.com (Dave Kellogg) (01/30/89)

In article <820@altos86.UUCP> jon@altos86.UUCP (Jonathan Ma) writes:
>In article <880@cantuar.UUCP>, paul@cantuar.UUCP (Paul  Ashton) writes:
>> I have been asked if I can get some information on database benchmarks
>> that vendors often publish results for.  The debit/credit and TP1
>> benchmarks are ones I am aware of, but have little information on.

>    Benchmark programs are generally available from the database vendors.
>	I got mine from both Informix (Credit/Debt) and Unify (TP1).  They
>	are very useful and easy to use too.  We are using TP1 to benchmark
>	our hardware and application software.

To overview this in a nutshell.

	*  TP1 has no published specification.  There are typically somewhat
	   severe differences in the way different vendors implement TP1.
	   Most vendors use the "DebitCredit" transaction as defined in 
	   the DebitCredit benchmark, but ignore many other parameters specific
	   in DebitCredit (e.g. database size).  In short, TP1 is usually some
	   degenerate form of DebitCredit.  How different people degenerate is
	   not always the same.

	*  DebitCredit has a published specification which was written by 
	   Jim Gray of Tandem along with 20+ "friends" (from many different 
	   firms and universites) as contributors and reviewers. The spec
	   was published in two places.  It, unless you have old copies of 
	   Datamation lying around, is probably most easily obtained by asking
	   Tandem.

	   1. "A Measure of Transaction Processing Power", Tandem Technical 
	       Report TR85.2.  February 1985, Tandem Computers

	   2. "A Measure of Transaction Processing Power", Datamation, Volume
	       31, Number 7, 1985


David Kellogg
davek@rtech.rtech.com



>
>	-Jon-		Jonathan Ma, Altos Computer Systems
>				UUCP: {pyramid,sun}!altos86!jon

gupta@cullsj.UUCP (Yogesh Gupta) (02/08/89)

In article <2632@rtech.rtech.com>, davek@rtech.rtech.com (Dave Kellogg) writes:
> 
> To overview this in a nutshell.
> 
>  [A succint comment about TP1]
> 
>  [A brief history of DebitCredit]
> 
> 	   1. "A Measure of Transaction Processing Power", Tandem Technical 
> 	       Report TR85.2.  February 1985, Tandem Computers
> 
> 	   2. "A Measure of Transaction Processing Power", Datamation, Volume
> 	       31, Number 7, 1985
> 
> 
> David Kellogg
> davek@rtech.rtech.com

One thing that people may want to note is that NO commercial vendor
today (including Tandem) does the DebitCredit benchmark as specified
by Anon et. al. in their paper(s) in 1985.  The places where DebitCredit
is compromised is:

   1) the size of the database;
   2) the number of terminals simulated;
   3) the response time limitation;
   4) the think time interval;
   5) the network component.

Also, it is important to note that the paper did NOT emphasize the
transaction rate alone, but the cost per transaction as well.  Most
vendors today calculate their costs differently from the way the
paper specifies or the way the other vendors calculate, making the
numbers VERY hard to compare.

However, even with the above state of affair, there is hope in that
there exists a council trying to standardize a benchmark which is similar
to the DebitCredit to clear up some of this.  And yes, I think almost
all the DBMS vendors are participating!
-- 
Yogesh Gupta                    | If you think my company will let me
Cullinet Software, Inc.         | speak for them, you must be joking.