Re: number of transactions per minute/hour


The most important aspect as Anjo and Niall have pointed out is "define 'transaction'".


A. I could have one OLTP Database application "X" where, on average, user DML is 10 rows of 120 bytes each
per COMMIT ('user commits' from v$sysstat)
I could have another OLTP Database application "Y" where, on average, user DML is 3 rows of 50 byte each
per COMMIT.('user commits' from v$sysstat)


If I count 'user commits' , can I compare the "throughput" of System X against System Y ?

B. My OLTP Database application (say eBusiness Suite) runs batch jobs of 1000s of rows 5pm to 8pm daily.
During the period 2pm to 5pm, user Data Entry is 2 rows each COMMIT.
Can I compare 'user commits' for the period 2pm-5pm against 'user commits' for the period 5pm to 8pm
and draw the conclusion that the "system is slower in the evening because throughput as measured
in TPS is lower" ?


I generally do not want to use a count of COMMITs. When reporting database loads, I report
figures like 'redo size' (archivelog sizes), buffer gets, physical reads, peak concurrent sesssions,
%wait time on 'db file sequential reads', 'db file scattered reads', 'CPU used by this session' etc.,
explaining what each of these statistics mean.



At 04:09 PM Friday, Niall Litchfield wrote:

Well a benchmark worth its salt will of course define its own transactions. For example the tpc-c benchmark describes tpm as



TPC-C Benchmark Results



Q: What do TPC-C throughput numbers mean?

A: You must understand what the benchmark is intended to measure, before you can understand throughput. Throughput, in TPC terms, is a measure of maximum sustained system performance. In TPC-C, throughput is defined as how many New-Order transactions per minute a system generates while the system is executing four other transactions types (Payment, Order-Status, Delivery, Stock-Level). All five TPC-C transactions have a certain user response time requirement, with the New-Order transaction response time set at 5 seconds. Therefore, for a 710 tpmC number, a system is generating 710 New-Order transactions per minute while fulfilling the rest of the TPC-C transaction mix workload.

You could also take a wander over to <http://dominicgiles.com/swingbench.html>http://dominicgiles.com/swingbench.html and take a look at how the swingbench oracle performance testing tool works - you can extend it yourself as well.


So benchmarks returning transactions per minute is simple, the definition and measure are all defined in the benchmark. The real issue of course is how you define your own transactions. To be honest I'd measure Oracle transactions/minute as a proxy for real transactions - with the proviso that application upgrades and changes make the comparisons unreliable except in very general terms. .



On 9/15/06, LS Cheng <<mailto:exriscer@xxxxxxxxx>exriscer@xxxxxxxxx> wrote:
> Not sure but I think it is very tedious to get those figures.... I always
> wondered how benchmark tools gives you informations such as transaction per
> minute, I think those tools dont use v$sysstat for these purposes
>
>
>
>
> On 9/14/06, amonte <<mailto:ax.mount@xxxxxxxxx>ax.mount@xxxxxxxxx> wrote:
> >
> >
> > Hi
> >
> > DELETE/UPDATE/INSERT/SELECT, non-recursive SQL.
> >
> > In this database it only houses an application under a schema.
> >
> > Thanks
> >
> > Alex
> >
> >
> >
> > On 9/14/06, Anjo Kolk <<mailto:anjo.kolk@xxxxxxxxxxx>anjo.kolk@xxxxxxxxxxx > wrote:
> > >
> > > Define USER transaction.
> > >
> > >
> > >
> > > On 9/14/06, amonte <<mailto:ax.mount@xxxxxxxxx>ax.mount@xxxxxxxxx> wrote:
> > > >
> > > > Hi
> > > >
> > > > Does anyone know how to obtain the number of USER transactions per
> hour? Or per minute?
> > > >
> > > > I know from user commits and user tollbacks we can get roughly the
> number of Updates/Inserts/Deletes. However I am also interested in SELECT.
> > > >
> > > > I have looked at:
> > > >
> > > > Parse calls, not good since it wont give correct numbers if my
> application behaves well and dont use event soft parses.
> > > > Execute count, not good because I am not sure why, sometimes for each
> query it increases by 1 but sometimes by 3, 4, or 5 or even more. This has a
> problem because it includes recursive calls as well.
> > > >
> > > > TIA
> > > >
> > > > Alex
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > Anjo Kolk
> > > Owner and Founder OraPerf Projects
> > > tel: +31-577-712000
> > > mob: +31-6-55340888
> >
> >
>
>



-- Niall Litchfield Oracle DBA <http://www.orawin.info>http://www.orawin.info


Hemant K Chitale
http://web.singnet.com.sg/~hkchital


-- http://www.freelists.org/webpage/oracle-l


Other related posts: