slow data delivery rate via Pro*C ?

From: P. Singleton <csa09_at_seq1.keele.ac.uk>
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.

The root of the problem is the low bandwidth from Oracle to our applications. Once the SELECT query has been evaluated (no complaints about the speed of this), the resulting tuples are delivered at a disappointingly leisurely rate.

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 713082
Received on Thu Jan 16 1992 - 16:17:56 CET

Original text of this message