mat@amdahl.UUCP (04/10/87)
In article <682@dlvax1.datlog.co.uk>, ajs@datlog.co.uk ( Andy Simms ) writes: > > More and more relational database vendors are quoting transaction throughput > rates in terms of the TP1 benchmark. > I have recently seen programs purporting to conform to this definition of TP1 > that lead me to believe quoted transaction rates are misleading: > > 1. TP1 is run as a single process and is therefore measuring > batch-style transactions rather than on-line ones. What is wrong with this procedure? If the vendor wishes to run only one transaction at a time, he is probably limiting his performance. There is nothing wrong with queuing the input messages and then feeding them one at a time into a single process (so long as the cost of doing this is accounted for, and response time constraints are met. Any throughput benchmark of this type must set a response time requirement or it is meaningless. .P Many 370-world transaction processing systems use some fixed number of processes which is much less than the number of users and assign transactions to processes as they are scheduled. A process is not committed to a user, but is more likely to be committed to a transaction type for efficiency reasons. > 2. The programs I saw did NOT include the ESSENTIAL begin/commit > pair (essential to maintain the integrity of the database). This, of course is unforgivable, and renders the results pretty meaningless. Transaction systems must pass the ACID test - Atomic, Consistent, Independent, Durable. Otherwise they are toys. -- Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]