• No results found

Implementation Constraints

In document dtj v03 01 1991 pdf (Page 49-51)

The TPC Benchmark A imposes several condi tions on the test environment.

• The transaction process ing system must support

atomicity, consistency, isolation, and durability (ACI D) properties during the test.

• The tested system must preserve the effects of

com m i t ted t ransactions and ensure database consistency after recovering from

- The fa il ure of a single durable medium that conta ins datatbase or recovery log data - The crash and reboot of the system - The loss of all or part of memory

Digital Tecbt�ical ]ourttal Vol. 3 No. I \Vittter 1991

• Eighty-five percent of the accounts processed

by a teller must belong to the home branch (the one to which the teller belongs). Fifteen percent of the accounts processed by a teller must be owned by a remote branch (one to which the tel ler does not belong). Accounts must be uni­ formly d istributed and randomly selected.

Database Design

The database consists of four individual files/tables:

Branch, Tel le r, Account, and History, as defined in Table 1 . The overal l size of the database is deter­ mined by the throughput capacity of the system. Ten tellers, each entering transactions at an aver­ age rate of one transaction every 10 seconds, gener­ ate what is defined as a one-TPS load . Therefore, each teller contributes one-tenth ( 1/10) TPS. The history area must be large enough to store the his­ tory records generated during 90 eight-hour days of operation at the published system TPS capacity. For a system that has a processing capacity of

x TPS, the database is sized as shown in Table 2. For example, to process 20 TPS, a system must use a database that includes 20 branch records, 200 teller records, and 2, 000,000 account records. Because each teUer uses a term inal, the price of the system must i nclude 200 term inals. A test that results in a higher TPS rate is invalid un less the size of the database and the number of termi nals are increased proportionately.

Transaction Processing, Databases, and Fault-tolerant Systems

Table 1 Database Enti ties

Record Bytes Fields Required Description

Branch 1 00 Branch_ID

Branch_ Balance

Identifies the branch across the range of branches Contains the branch's current cash balance

Teller 1 00 Teller_ID

Branch_ID

Teller _Balance

Identifies the teller across the range of tellers Identifies the branch where the teller is located Contains the teller's current cash balance

Account 1 00 Account_ID

Branch_ID Account_Balance

Ident ifies the customer account uniquely for the entire database Identifies the branch where the account is held

Contains the accoun t's current cash balance

History 50 Account_ID

Teller_ID Branch_ID Amount

Identifies the account updated by the transaction Identifies the teller i nvolved in the transact ion Identifies the branch associated with the teller

Contains the amount of credi t or debit (delta) specified by the transact ion

Time_ Stamp Contai ns the date and time taken between the BEGIN TRANSACTION and CO M M IT TRANSACTION statements

Table 2 Database Sizi ng

Number of Records 1 X X 1 0 X X 1 QQ,QQQ X X 2,592,000 X X

Benchmark Metrics

Record Type Branch records Teller records Account records H istory records

TPC Benchmark A uses two basic metrics:

• Transactions per second (TPS) - throughput in

TPS, subject to a response time constra i n t, i.e. , the MQTh, is measured whi le t he system is in a susta i nable steady-state cond ition.

Price per TPS (K$/TPS) - the purchase p rice and five-year maintenance costs associated with one TPS.

Transactions per Second To guarantee that the tested system provides fast response to on-line users, t he

TPC

Benchmark A imposes a sp ecific response t ime constraint on the benchmark. Ninety p e rcent of al l transactions must have a response time of less t han two seconds. The TPC Benchmark A standard defines transaction response time as the time i nterval between the trans m ission from the termi nal of t he first byte of the input mes­ sage to the system under test to t he arrival at the term inal of the last byte of the outpu t message from t he system under test.

The reported TPS is the total nu mber of com m i t­ ted t ransactions that both started and completed

48

during an i nterval of steady-state performance, d ivided b y the elapsed time of the i nterval . The steady-state measurement i nterval must be at least

15 m inures, and 90 percent of t he transactions must have a response time of less t han 2 seco nds.

Price per TPS The K$/TPS price/performance metric measures the total system p rice in t hou­ sands of dollars, normal i zed by the TPS rating of the system. The priced system i n cludes all t he components that a custo mer requires to achieve the reported perform ance level and is defi ned by the TPC Benchmark A stand ard as t he

• Price of the system under test, including all hard­

ware, software , and ma i ntenance for five years.

• Price of the terminals and n etwork compo­

nents, and their mai ntenance for five years.

• Price of on-line storage for 90 days of h istory

records at the publ ished TPS rate, which amounts to 2,592,000 records per TPS. A storage medium is considered to be on-line if any record can be accessed randomly within one second.

• Price of addi tional products required for the

operation, adm i n istration, or m a i n tenance of the priced systems.

• Price of p ro d ucts required for application

development.

Al l hardware and software used in the tested configuration must be announced and general l y ava i lable to customers.

In document dtj v03 01 1991 pdf (Page 49-51)

Related documents