Figuring out peak TPS rates

What is a good way to go about calculating "peak" transactions per second hitting a database?

Yes, a statspack report gives you that information. But it is averaged out over the time period (15 minute or whatever) of the snapshot ids. Obviously this number could be significantly skewed. Say you have 100 transactions hitting the database over 1 minute, and 0 over the next 14 minutes - statspack will report TPS as 100 / (15x60)..which is significantly lower than the number that I'm looking for - peak = 100 / (1x60).

Running statspack snapshots at 1 minute intervals doesn't seem practical either.

Not sure how to go about this..

The only way I see it run 100 transactions continously for 5 min, and then take statspack report. It is easy to set up through dbms_job.

Tamil

Tamil - thanks.

I posted the same question on Asktom later. This is what he had to say. He asks me to go by "commits".

http://asktom.oracle.com/pls/ask/f?p...39778386806676

Of course, being pedantic, there can only be one commit per transaction, since a transaction is ended with a commit (or rollback). I suppose "application unit of work" (AUW?) should be used instead.

Using transations/second as a metric is not meaningful unless you say how "big" the transactions (AUW's) are to be. Is that clear in the application?

400 commits/second could be only 40 AUW's/second . . . .

Just curious - how do application vendors come up with hardware recommendations based on TPS rates?

Say a Sun 480, 2 CPU machine can handle 40TPS *on paper*. Now, it is certainly possible that the complexity of the actual custom application's transaction mix is a lot more (complex) than the routine OLTP transaction mix that these benchmark tests are run on..
So even with a fudge factor of 2, it is quite possible that a mere 20TPS will bog down this Sun 480 box.

Bottomline, do you just take for granted that the application vendor knows what they're talking about..and they know the complexity of the transaction mix etc. (Yes, hence the need to test, test, test..I know that bit).