slow data delivery rate via Pro*C ?
Date: 16 Jan 92 15:17:56 GMT
Message-ID: <2018_at_keele.keele.ac.uk>
I use Oracle V6 on a Sun 4 network to serve a prototype CASE system via the Pro*C interface.
The RDBMS contains data on about 15,000 program fragments (cross-references, types, language details, keywords etc.).
Oracle replaced a previous storage scheme of simple flat files, which was generally slow both to search and to update.
Unfortunately, although some applications are now much faster (and, more importantly, some are feasible where they were not before), others are slower, much to our disappointment.
To illustrate this, I wrote minimal 'C' programs to read large amounts of data from
UNIX files via 'read' system calls UNIX files via the 'stdio' interface Oracle via the Pro*C interface (SELECT * FROM BIG_TABLE)
On a Sun 4/380 with local Oracle V6 and local fast SMD discs, the bandwidths (in kilobytes per second) were:
local remote ===== ====== raw file read 700 280 stdio file read 400 270 Pro*C retrieval 16 7
Remote file reading uses NFS; remote Pro*C retrieval uses SQL*Net and TCP/IP. I calculate the Pro*C rate as size of nul-terminated strings (including the nuls) divided by real time to deliver them. To reduce the effect of caching, I read a 60 Mbyte file and retrieved a multi-Mbyte table.
16 kbytes/sec may be faster than a user can read a scrolling display, but my application would be better served by a rate ten times this. Is this too much to expect?
My Pro*C program closely follows the examples in the User's Guide, but I notice that SQL*Plus is capable of retrieving the same data faster than my Pro*C program, so I live in hope.
I wonder if any other commercial database performs significantly better in this respect?
-- __ __ Paul Singleton (Mr) JANET: paul_at_uk.ac.keele.cs |__) (__ Computer Science Dept. other: paul_at_cs.keele.ac.uk | . __). Keele University, Newcastle, tel: +44 (0)782 621111 x7355 Staffs ST5 5BG, ENGLAND fax: +44 (0)782 713082Received on Thu Jan 16 1992 - 16:17:56 CET