Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsl!sdo From: sdo@cbnewsl.att.com (scott.orshan) Newsgroups: comp.benchmarks Subject: Re: TPC-B - is this really progress? Message-ID: <1991Apr8.172020.21567@cbnewsl.att.com> Date: 8 Apr 91 17:20:20 GMT References: <115440007@hpcuhc.cup.hp.com> Organization: UNIX System Laboratories Lines: 42 Is there any transaction processing benchmark that addresses cost per user rather than cost per TPS? The TPC results are for a given number of users (about 10X the TPS rating). I think a more useful rating would vary the number of users up to some very large number, maybe ten times the nominal TPC number of users. The database size would be constant. The reported costs would show the incremental cost per user, and the maximum ultimate limit of users. The think time could be lengthened to accommodate the extra users. Here's why this is useful. Suppose I need to support 1000 users, generating an equivalent of 50 TPC-A TPS. Anyone reporting TPC numbers will only run with 500 users for that throughput level. I want to know whether a 50 TPS system can support 1000 users - I want to decouple the TPS rating from the number of users. Given two 50 TPS systems, it could be that one is at the upper limit of its configurable resources, while the other could easily scale to double the number of users. Not counting the problems of database replication, I want to know whether it is cheaper to buy two 500 user systems or one 1000 user system. Note that each of the 500 user systems would only run at 25 TPS, since my hypothetical users don't deliver requests as fast as TPC front ends. It's not too hard to figure out an approximate TPC-equivalent rating for an application (at least within a factor or two or three), but there's no way to know if another network connection can be made, or another process attached to a DBMS unless the vendors report it. In the absence of this information, I would have to start with TPC-B numbers and price out a configuration for each Vendor/DBMS combination, and then see if the DBMS would work with that many users. Any comments on this? Scott Orshan UNIX System Labs 908-522-5063 attunix!sdo sdo@attunix.att.com