| � <<< Note 1237.0 by TRCU11::WEISS >>>
� -< System Sizing using Debit/Credit Transactions >-
********** DIGITAL INTERNAL USE ONLY **************
Hi Ira,
I am in the TNSG/Software Performance Group and our group conducts many
of the Debit/Credit (TPC-A,TPC-B) benchmarks you have seen information
on. Let me respond to some of your concerns.
You have a very difficult job to do given the limited amount of
information available to you. I would be very uneasy about giving the
customer any concrete numbers because I do not think they exist with
the data currently available.
I do have one question before I answer your questions. How does the
customer know the number of reads/txn and write/txn when they haven't
even defined the database? I guess they could tell you what they want
the IO to be but this would be of limited usefulness when trying to size
the actual system.
First, you mentioned that Debit/Credit transactions require 50K
instructions to complete. Debit/Credit transactions (TPC-A transactions)
are executed through the TPC-A workload. In this workload, TPC-A
transactions have two execution components (the back-end (BE) execution
component and the front-end (FE) execution component). With Rdb 4.2 and
a highly tuned database and transaction, we see 57K VAX instructions/txn
for the BE portion on a 6610, at 96% CPU utilization, at 102.30 tpsA.
With different versions of Rdb, different version of ACMS and .... that
number will change (we expect this number to be even better with future
versions of Rdb). If we were to use 1 VUP = 1*10^6 and 32 VUPS for the
6610 we could conclude that the number of VAX instructions for the
transaction was 300K VI/txn but this is not the case. What are the
causes of this difference:
1) with a TPC-A mix of transactions the 6610 executes 6.2MVI/sec on the
back-end (this number is measured and workload DEPENDANT)
2) the VUP rating is more accurate when dealing with well cached
technical workloads not commercial workloads such as TPC-A
3) the VUP is equivalent to 1*10^6 instructions for some competitors
but never VAX instructions even on a technical workload; a VAX
instruction is very powerful (CISC instructions) and can typically do
the work of 1-4 CISC instructions from other vendors or RISC
instruction sets
4) commercial workloads require frequent memory accesses
Some of the assumptions you made are also very dangerous. I have not
seen any TP/DB applications that really looks like Debit/Credit
transactions. In general, TPC-A transactions only use two IOs for data
retrieval and updates and this is extremely minimal from a transaction
perspective. Also, the application has limited conflict problems
because users are targetted at different data ranges within the
database. If you know the Reads/txn and Writes/txn you can at least
come up with an IO complexity ratio which compares your transactions to
TPC-A transactions. You can also develop a complexity ratio for the
level of locking and conflicts you will see in your transactions.
Delays are very important and cannot be overlooked. They should not be
assumed to be zero but rather some reasonable number should be used
based on the application circumstances. As delays go up, you will have
to have good parallelism to maintain high throughput levels (many
server/users executing the same set of transactions).
Good point about database design .... I completely agree with you.
Database design is crucial to good response time (and it takes time to
get a good db design). To come up with a good number for the number of
VAX instructions per transaction you will need some knowledge of the
transactions (i.e. number of SQL statements, # records involved, IOs
involved, relationships between the transactions, etc). Each one of
these can have a set of assumptions associated with them.
I hope this will help .............
Mike Brey
COOKIE::BREY
********** DIGITAL INTERNAL USE ONLY **************
|