Re: ** FOR IMMEDIATE RELEASE - RECORD-BREAKING TPC-C RECORD!! **

In article <47dup1$q2s@fido.asd.sgi.com>, gainer@gainer.engr.sgi.com (Patrick Gainer) writes: > In article <47dn67$ni4@pong.lasc.lockheed.com>, > Terry Greenlaw <z50816@mip.lasc.lockheed.com> wrote: > > [stuff deleted] > Usually the benchmarking process goes a little like this: > > 1, Decide what tpmC number you wish to try to obtain. Let's use 5000 tpmC > as an example. > > 2, Build a database with the number of warehouse table rows equal to 1/11 > of the desired tpmC. In this case, we'd use a 450 warehouse row > database (AKA a "scale 450" db). The 1/11 figure is a rule-of-thumb, > not an absolute value. > > 3, This database is about 45 GB in size (using a back-of-the-envelope > 1 GB per 10 warehouse rows.). > > 4, Start benchmarking. Using a scale 450 db, you are *required* to use > 4500 users. The only way to alter this values is to change the size > (scale) of your database. > > 5, If you have sufficient hardware and a fast RDBMS engine, you may > obtain your goal. If you don't, you scale back the database size > and try it again. > > Most unix RDBMS can not handle 5000-10,000 users gracefully. Instead, most end up > using a transaction monitor to multiplex users down to somewhere in the area of > 50-350 database connections. So despite the large number of connected users seen > in the benchmark, usually there are only really a couple hundred actual db > connections. So your point about needing 8000 users for good numbers is misleading > at best and conceptually wrong. > > So really, the TPC-C benchmark isn't so much smoke and mirrors as you have > insinuated. The terminal concentrators etc are there because the benchmark > spec basically requires them to be there. > > >Until TPC enforces the benchmark more rigidly, it's pointless to try and > >compare. > > It is enforced extremely rigidly. You have obviously never been remotely > involved in a TPC-C benchmark or you would not be saying such things. > Hey, I used to work for Oracle. I know all about "tuning" benchmarks to produce a customer-requested number ;-} I just can't stomach anyone trying to claim that these numbers are even remotely related to anything that 99 percent of RDBMS users are trying to achieve with their systems. > The TPC-C numbers may be compared absolutely. The only variables a customer > should assume are the hardware differences and the RDBMS engine differences. > Apart from this, the work done in the benchmark and the rules governing > the response times, throughput, SQL executed, users, etc are identical. > > Pat So, let me see if I've got this straight. I'm trying to purchase a database for my company. An example of real-world constraints would be: 1) I have $1,500,000 to spend 2) I have 100-120 concurrent users 3) My entire database is currently 20GB with approx. 15% growth/year And you're claiming a realistic benchmark can be found by: 1) Picking the result you want 2) Making the database big enough to support your hypothesis 3) Making the number of users large enough to support your hypothesis 4) Buy sufficient additional components to support n users My three fixed variables are money, users, and db size. Your only fixed variables are TPC-C result and hardware platform. How can your benchmark help me decide which machine/database to purchase? I don't have 8000 users. I don't have 400GB of data. I definitely don't have $3,000,000. The machine I purchased at $120,000 would have to have an additional $1,300,000 in upgrades to meet your TPC-C numbers. All I wanted to know was what kind of performance I should expect from machine X running database Y relative to machine Q or database Z. Isn't that the purpose of a benchmark? All the TPC-C numbers I've seen to date are for unrealistic business environments. My car goes 130 MPH and uses no gas. Did I mention I dropped it out of a B-52 bomber? Sorry for the rant, but this is a definite sore spot... tog Terry Greenlaw (on-site @ Lockheed Martin) Encompass Technologies z50816@mip.lasc.lockheed.com terry@encompass.is.net