Re: How can I get throughput of informix such as how many query/update operations per second?
HI Zachi,
Thans for your reply.
I knwo it depends on many factors, however, I want to know how to
estimate the expierenced value range of the throughput for an existing
system
> your server hardware:
> CPU performance
> number of CPUs
> amount and speed of memory
> storage system bandwidth
>
> your storage system:
> I/O bandwidth
> cache size
> disk rotational speed
> number of disks
I think, the above factors can be thought as the tpmC value of the
server.
Then we know the effect of the above factors.
>
> your application:
> the exact queries (OLTP or DSS)
> size of transactions and result sets
> size of tables and indices
> query optimization (indices and directives)
> database version
> use of replication (HDR and/or CDR)
The transactions can be supposed as the simplest query/update
operation, and index path is used, and the latest informix version is
used.
>
> your database layout:
> logs placement
> tables and indices placement
> fragmentation scheme
> appropriate statistics gathering
The layout can be supposed to be best.
So, we know the effect of the all the above factors.
Then how we can estimate the throughput?
I think the throughput has relationship with the ability of processing
in parallel of the
oninit process.
I guess throughput * response time = ability of processing in
parallel(how many transactions are being processed at ANY time).
If the reponse time and ability of processing in parallel are given,
then the throughput can be calculated.
The response time can be test out on current system, and the ability of
processing in parallel, I think, is decided by the design of oninit
process.
So if the latter is given, then the thourghput can be calculated out.
Do you know how can we estimate the number of transactions which are
being processed in parallel for one oninit process which used for
CPU(the other oninit can be supposed as enough) or for one init which
used for internal socket(the other oninit can be supposed as enough)?
In fact, I want to estimate the throughput of informix with quene model
by the following steps:
1 test the response time of each transation such as
quey/update/insert/delete
2 estimate the number of transactions which can be being processed in
parallel for oninit
3 calculate the throughput of the system
Thank you.
"Zachi 写道：
"
> eagle_jyjh@citiz.net wrote:
> > Given an database, how can I get the throughput of informix ?
> > such as how many query/update opertions per seconds informx can
> > support?
> > Because my application may submit serveral thousands of database
> > operations per seconds,
> > I want to calculate how many prcocess of my application can be started.
>
>
> The short answer is: "that depends".
>
> The longer answer is:
>
> That depends on:
> your server hardware:
> CPU performance
> number of CPUs
> amount and speed of memory
> storage system bandwidth
>
> your storage system:
> I/O bandwidth
> cache size
> disk rotational speed
> number of disks
>
> your application:
> the exact queries (OLTP or DSS)
> size of transactions and result sets
> size of tables and indices
> query optimization (indices and directives)
> database version
> use of replication (HDR and/or CDR)
>
> your database layout:
> logs placement
> tables and indices placement
> fragmentation scheme
> appropriate statistics gathering
>
> and probably a few (many?) more factors that escape me at the moment.
> Whole books were written on the subject - there isn't an easy answer.
>
> Zachi
eagle_jyjh@citiz.net wrote:
> HI Zachi,
> Thans for your reply.
> I knwo it depends on many factors, however, I want to know how to
> estimate the expierenced value range of the throughput for an existing
> system
>
>
>
>
> > your server hardware:
> > CPU performance
> > number of CPUs
> > amount and speed of memory
> > storage system bandwidth
>
>
> >
> > your storage system:
> > I/O bandwidth
> > cache size
> > disk rotational speed
> > number of disks
>
> I think, the above factors can be thought as the tpmC value of the
> server.
> Then we know the effect of the above factors.
>
>
> >
> > your application:
> > the exact queries (OLTP or DSS)
> > size of transactions and result sets
> > size of tables and indices
> > query optimization (indices and directives)
> > database version
> > use of replication (HDR and/or CDR)
> The transactions can be supposed as the simplest query/update
> operation, and index path is used, and the latest informix version is
> used.
>
> >
> > your database layout:
> > logs placement
> > tables and indices placement
> > fragmentation scheme
> > appropriate statistics gathering
> The layout can be supposed to be best.
>
>
> So, we know the effect of the all the above factors.
> Then how we can estimate the throughput?
> I think the throughput has relationship with the ability of processing
> in parallel of the
> oninit process.
>
> I guess throughput * response time = ability of processing in
> parallel(how many transactions are being processed at ANY time).
> If the reponse time and ability of processing in parallel are given,
> then the throughput can be calculated.
> The response time can be test out on current system, and the ability of
> processing in parallel, I think, is decided by the design of oninit
> process.
> So if the latter is given, then the thourghput can be calculated out.
>
> Do you know how can we estimate the number of transactions which are
> being processed in parallel for one oninit process which used for
> CPU(the other oninit can be supposed as enough) or for one init which
> used for internal socket(the other oninit can be supposed as enough)?
>
> In fact, I want to estimate the throughput of informix with quene model
> by the following steps:
>
> 1 test the response time of each transation such as
> quey/update/insert/delete
> 2 estimate the number of transactions which can be being processed in
> parallel for oninit
> 3 calculate the throughput of the system
>
>
> Thank you.
>
>
>
>
> "Zachi 写道：
> "
> > eagle_jyjh@citiz.net wrote:
> > > Given an database, how can I get the throughput of informix ?
> > > such as how many query/update opertions per seconds informx can
> > > support?
> > > Because my application may submit serveral thousands of database
> > > operations per seconds,
> > > I want to calculate how many prcocess of my application can be started.
> >
> >
> > The short answer is: "that depends".
> >
> > The longer answer is:
> >
> > That depends on:
> > your server hardware:
> > CPU performance
> > number of CPUs
> > amount and speed of memory
> > storage system bandwidth
> >
> > your storage system:
> > I/O bandwidth
> > cache size
> > disk rotational speed
> > number of disks
> >
> > your application:
> > the exact queries (OLTP or DSS)
> > size of transactions and result sets
> > size of tables and indices
> > query optimization (indices and directives)
> > database version
> > use of replication (HDR and/or CDR)
> >
> > your database layout:
> > logs placement
> > tables and indices placement
> > fragmentation scheme
> > appropriate statistics gathering
> >
> > and probably a few (many?) more factors that escape me at the moment.
> > Whole books were written on the subject - there isn't an easy answer.
> >
> > Zachi
I'm afraid your view of the system is too simplistic. Load effects are
highly
non-linear, and by measuring the time of single operations you are
missing
the effects that various operations have on each other. Orders of
magnitude
difference in response time are between operations which access data
that is
in memory vs. data that needs to be fecthed from storage, and these
types
of cross effects need to be taken in consideration. The distribution of
the data
to be written also matters a lot: if your operations need to update
indices, or
are rewriting data in memory, adding or updating random blocks.
That said, Informix is known to be a very lean and mean machine, which
gives
exceptional performance on very modest hardware - assuming you have
enough
memory for your data set size and load.
I'm sorry I cannot give you numbers - I doubt anyone can give you
numbers that
fit *your* system.
Zachi