|
I know it's a long time since you asked the question, Richard, but
just in case you didn't see this, I'll put it in here. Quite
interesting what 64 bits can give you ..
cheers,
- Lars
From: MEMIT::SANBORN "21-Feb-1994 1450" 21-FEB-1994 14:52:27.22
To: @CICS.DIS
CC: SANBORN
Subj: Informix 64-bit benchmark in AYR
------- Forwarded Message
Return-Path: hall
Message-Id: <[email protected]>
To: upmm
Cc: [email protected]
Subject: Want to speed up your tp numbers by 7? Your application by 46 times?
Date: Sun, 13 Feb 94 18:39:22 -0500
From: "Jon 'maddog' Hall, USG Product Management" <hall>
X-Mts: smtp
Hi,
Some of you have heard about the work with Informix about "taking advantage
of 64-bits", but a lot of you do not know how much of "an advantage" it could
be.
Well, the simple act of *PATCHING* the Informix code to allow for really
large buffers allowed for a seven time speed-up in OLTP transactions, and
a 46 times speed up in decision support applications. This would not work
with any 32 bit system, since the database engine would not be able to have
all the data in memory at one time due to the limitation on virtual memory
size.
This requires *NO* changes to the client application, and (obviously)
minimal changes to the database engine.
Just thought you might like to know. I will be getting a copy of his
benchmarking results, and will circulate them when they arrive.
md
==============================================================================
From: MUNICH::KRNETA "Paul Krneta, Open Systems Services
Center(OSSC) Munich" 14-DEC-1993 20:32:15.08
To: @IFX
CC: KRNETA
Subj: Informix 64-bit benchmark in AYR
Subject: 64 bit computing demonstrated with Informix OnLine
Executive Summary:
==================
Concrete proof points of the benefits of 64 bit computing was established
in a benchmark run in Ayr, Scotland during the week of 29.11.93 - 3.12.93.
The main results were:
1) OLTP transactions run up to 7 times faster
2) Decision support applications run 46 times faster
The basis for these tests was Informix OnLine 5.00 UD2 running
under OSF/1 version 1.3. This version of Informix was patched by the
Informix porting center in London together with Paul Krneta from the BPDA
center in Munich, Germany, in order to support an unlimited sized database
buffer. Using large database buffers affects the data integrity in no way
whatsoever. The real benefits of using a 64 bit capable database are:
1) Any application using the database can immediately take advantage
of 64 bits, new CPU and RAM technology with NO modification.
2) No 32 bit UNIX vendor can offer this performance advantage, until
they too are capable of 64 bits.
The Benchmark
=============
The main goal of the test was to demonstrate the performance advantage of
a system configuration using more than 32 bits of physical address space.
The test system was a DEC 7000/610 (182 MHz CPU) configured with 3.5 GB
of RAM and 24 GB disk. Two cases were benchmarked:
1) Mainframe - configuration 3.3 GB RAM dedicated to Informix buffers
2) Workstation - configuration 0.4 GB RAM dedicated to Informix buffers
NOTE:
a) All 32 bit UNIX systems allow up 2 GB virtual address space/ process
b) In Q3FY94 we will be able to configure up to 14 GB RAM in the DEC 7000
The performance relationship between the two cases was measured with two
types of database loads.
1) Simple Queries: OLTP transactions. This test used the standard TPC-B
source code, with a database size of 3GB. The results cannot be used
as an audited TPC-B result.
2) Complex Queries: decision support, report generation, complex table
lookup operations, ... (similar to TPC-C/D benchmarks)
Informix UK was actively involved in defining and performing the benchmark.
We are now working together to get the Informix UK patches integrated into
the main source pool in Menlo Park.
Summary of Results:
===================
1) Simple Queries ( performance ratio: 7:1)
a) Mainframe configuration: 288 transactions/sec (tpsB-like)
b) Workstation configuration: 40 transactions/sec (tpsB-like)
NOTE:
a) With 14GB memory, we could generate an auditable TPC-B result
b) HP's largest single processor configuration (HP 9000 H50) is
quoted with 170 TPC-B transactions
2) Complex Queries ( performance ratio: 46:1)
SQL query on TPC-B database: (select max(abalance) max_bal from history
h,accounts a where a.aid = h.aid; )
a) Mainframe configuration: 26 sec
b) Workstation configuration: 1207 sec
NOTE:
a) This is a typical report generation query (using random
indexed queries, joins, sorts on a 3GB database)
Conclusion:
===========
A 64 bit capable database on Alpha AXP gives us a unique opportunity to
provide a mainframe class solution using a standard UNIX platform NOW.
Alpha AXP with DEC OSF/1 can therefore be deployed quickly as the "database
accelerator" for mainframe environments, opening the door for Digital in
previously inaccesible accounts. This makes DEC OSF/1 an ideal downsizing
target.
Full benchmark results are available upon request. For further information
please contact Paul (MUNICH::) Krneta, DTN 865-2529.
------- End of Forwarded Message
================== RFC 822 Headers ==================
Received: by xirtlu.zk3.dec.com; id AA17582; Tue, 15 Feb 1994 16:11:23 -0500
Received: by blkang.zk3.dec.com; id AA24845; Tue, 15 Feb 1994 16:11:23 -0500
Message-Id: <[email protected]>
Date: Tue, 15 Feb 94 16:11:22 -0500
X-Mts: smtp
From: MUNICH::KRNETA "Paul Krneta, Open Systems Services
Center(OSSC) Munich" 21-FEB-1994 20:06:08.53
To: STKMTS::STKMTS::MRGATE::"A1STKAI1::BUBENKO.MIKAEL"
MUNDIS::MUNDIS::MRGATE::"GYMRC::RDGMTS::SUBURB::A1_CHEFS::WHITBYS"
MSBCS::DMCGINNIS MRGATE::"ufh::harald wulfken"
CC: TPSYS::SHEN SX4GTO::WANNOOR SNOC02::HAGARTYD OSLACT::BJORNAU,KRNETA
Subj: Informix 64-bit benchmark: seting the things straight
From: SX4GTO::KRNETA 21-FEB-1994 16:46:48.06
To: TPSYS::KOHLER HPCGRP::TASAR MSBCS::ANDRUS AMCUCS::RAMI
MR4MI2::PATEL
CC: NASAXP::BLAKE MSBCS::MILLER_M AMCUCS::JOLLEY MSBCS::TAUBE
NOVA::WAEL SFBAY::JIMGRAY MR4DEC::MGREENFIELD MTS$"wro::Anthony
Williams",KRNETA
Subj: Informix 64-bit benchmark: seting the things straight (2nd try)
In order to clarify the Informix 64-bit test and test results which
have caused a lot of activity and misinterpretations I'll reiterate the
scope and the goals of the AYR benchmark. Goals, NON-Goals were set by
John Pickford, John Billings(both of Informix UK) and myself.
1. The GOALS:
- to develop a proof-point of the advantages of the 64-bit
computing from TECHNICAL point of view.
- to DEMONSTRATE DIGITAL's ADVANTAGE from Marketing point of view
and position Digital as THE LEADER in this area.
- to DEMONSTRATE that Informix OnLine can use HUGE main memory that
only 64-bit computer (both HW and SW) like Alpha AXP and DEC OSF/1
can offer(and none of our competitors).
- to SHOW that ANY Application can take IMMEDIATE performance advantage
of such a system WITHOUT ANY CHANGES AT ALL.
- to DEMONSTRATE the performance differences between I/O bound and
CPU bound database applications.
- to DEMONSTRATE that customers will take advantage of new and faster
Alpha CPUs (EV5, EV6...) performance without having to EXTENSIVELLY
redesign their I/O subsystems or add another 50 or 100 disks.
We all know that in last 5 to 8 years RISC CPU performance increased
by factor of 100's while disk acces time improved by factor of 2 to 3
(limits if mechanics).
- to SHOW NEW, 64-bit type of data processing that will offer
QUANTUM LEAP in performance.
- to point out the application types which will take the MOST
ADVANTAGE( PERFORMANCE, PERFORMANCE) of huge main memory and
therefore be able to JUSTIFY the cost of additional memory.
2. NON-GOALS:
- to be a solution to all the problems we have with either our
competition or the performance of Informix OnLine on DEC OSF/1.
- to do a OFFICIAL TPC-B bechmark. TPC-B was used simply as something
easy to relate to. NEITHER of the TPC benchmarks(tpc-A, tpc-B, tpc-C)
will be useful simply becuse the OFFICIAL size of the database
scales with the tps rating thus not being able to cache the entire
database in memory.
- to trigger the discussion about already TECHNOLOGICALLY OBSOLETE
(but still used) tpc-A and tpc-B benchmarks.
- to fix all known database problems with GIGABYTES of RAM.
(Large DB cache will AGAIN help but will not fix the base problem)
- to discuss the performance of Informix OnLine 5.0x engine.
The choice of Informix as a case study was due to the willingness
of the Informix UK Porting Center to modify OnLine.
- to compare Informix OnLine 5.0x with other RDBMS such as Rdb,
Oracle etc.
- to put disk manufacturers out of business.
3. DEMONSTRATE ADVANTAGES of LARGE DB CACHE:
- RAPID acces time (=RAM access time) thus no waiting on the disk
- elimination(significant reduction) of read I/O
- elimination(significant reduction) of KERNEL time during reads
(FREEING UP the CPU to do REAL work and not handle read I/O)
- reduction of main memory trafic(much less DMA from disk to RAM)
- less context switching(less of kernel time)
- NO FUNCTIONAL CHANGES required in RDBMS code(data type change only)
with transaction log still on either magnetic or SSD and updates being
flushed/checkpointed in regular time intervals back to disk(s).
- much simpler I/O subsystem
(particularly for read only or read mostly applications)
- EVEN the DBs which can not entirely fit in DB cache will benefit
(thus not limiting the concept to the DB size up to 14 GB)
- Server performance(and thus application performance) will scale
almost linearly with both CPU perfomance and number of CPUs.
(has yet to be tested OSF/1 SMP).
Paul Krneta DTN 543-3210
|