Re: How fast is Oracle ?
Date: 1996/02/08
Message-ID: <4fdrit$js_at_news.ee.net>#1/1
Richard Armstrong <richard_at_juno.demon.co.uk> wrote:
>Can anybody suggest a rough estimate of the speed of Oracle 7.1 ? The
>company I work for is considering Oracle for the development of a real
>time system to record share price data. It needs to be able to receive
>about 300 data items per second from an external source and update
>corresponding records in an Oracle table (ie 300 update statements per
>second). The table has three integer fields. One field is changed on
>each update. Changes are committed after every hundred updates.
>We have written a test application using a DEC Alpha machine running
>OpenVMS 6.1 and Oracle 7.1. The application is written in Pro*Pascal
>and it can only manage around 20 or 30 updates per second. We don't
>know whether this is the maximum rate we can reasonably expect or
>whether further tuning effort is likely to yield improvements.
>We did notice a great deal of disk access by the log writer process
>which seemed to slow things down. Should this process only write after
>a COMMIT ? We have tried speaking to Oracle support in the UK but they
>have not been able to offer much help. We are now considering trying
>other databases such as Ingres to see how they compare.
>I will be very interested to receive any thoughts or comments anybody
>may have.
>--
>Richard
Richard,
That is very slow!
There are many factors to consider:
1. How much real memory does Oracle have.
It's sounds like your disk thrashing.
Oracle likes lots of memory. The buffers
are the single most critical element in
the Oracle archecture. For example, you
could buffer the entire NYSE given the
small row size of the table. The COMMIT
process is independent of disk i/o.
Disk i/o will occur as a result of
the kernel fetching data block for
rows not cached. Once a row is in cache
further updates go against memory (and
memory is fast). I am simplifing but
hopfully you get the gist of what I am
explaining.
2. The configuration of your hardware.
Is a fast caching controller employed,
problly not.
3. The data feed.
Is there bottlenecking?
Are you feeding the data directly
into the server with a process preparing
the UPDATE or is another machine preparing
the UPDATE over a network connection to the
server.
4.
the Client or is it being pipe in
to the Server
===================================================
!!!!!
/'_at_ @'\
+---------------oOOo-----U-----oOOo---------------+
| BigDaddy's Internet USENET FaxBack Service |
| 'never leave home without it' |
| |
| Mark Otero mpower_at_ee.net |
| MPower Your Future Today |
| 178 Beechbank Road (614) 338-1550 |
| Columbus, Ohio 43213-1261 Fax (614) 338-1553 |
+-------------------------------------------------+
| | | |
{__| |__}
Received on Thu Feb 08 1996 - 00:00:00 CET