Xref: utzoo comp.databases:2497 comp.lang.misc:2931 comp.software-eng:1495
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!vrdxhq!daitc!viusys!rwb
From: rwb@viusys.UUCP (Rick Butland)
Newsgroups: comp.databases,comp.lang.misc,comp.software-eng
Subject: Re: need help choosing between INGRESS and PROGRESS
Keywords: INGRESS, PROGRESS
Message-ID: <309@viusys.UUCP>
Date: 11 May 89 11:49:52 GMT
References: <985@resource.UUCP>
Reply-To: rwb@viusys.UUCP (Rick Butland)
Distribution: na
Organization: Unisys D.A. MINIS Branch, McLean, VA
Lines: 59


[ I tried to mail this, but my mailer puked on your address ]

I really don't have any experience with development using either package.
From what I've seen, I like both packages' development tools.

I just wanted to relate to you some problems I encountered with Progress
while benchmarking it.  I think that Progress has some real problems
dealing with a multi-user environment.  Performance, particularly on a
multi-processor machine, was poor.  The primary limitations I found were:

(Disclaimer:  These observations are based on an older release of Progress,
(3?), and may no longer apply.)

o  Single-server architecture.  In a multi-user environment, a database
server is started to service requests to access the database.  This, to me,
is a Bad Thing.  As the number of users began to rise, the server quickly 
became overwhelmed, due to the fact that it takes on the responsibility for
everything, from writing the before-image file, reading/writing the database,
parsing messages, servicing the message queues, managing data buffers, etc.  
As evidence of this, the benchmark I ran took a single user 8 seconds to
complete.  At 64 copies of the same program, with simultaneous starts,
the end-to-end time was around 1 hour 5 minutes.  This was a multi-processor
machine, (a three CPU Arix), however, after a period of time, the only
process eligible to run was the server, leaving the other two CPU's nearly
unused.

o  The handling of data buffers, (which are located in the dataspace of the
server), was poor.  Buffer lookup was obviously linear, rather than hashed,
thus contributing to the degradation problems.  Caveat:  Version 4 of 
Progress was to fix this.

o  Before-image handling - The problem here was that everytime you accessed
the database, a copy of the accessed page was written to the before-image file.
Unfortunately, it was always appended to the end of the file, and would not
reclaim unused space.  The file just continued to grow and grow, and at one
point, with a 100k database, I had a 11 MB before-image file.  The problems
of file system indirection really took a toll.  Caveat: in version 4, the
developers told me that they were going to build in a mechanism that would
rewind this file, when there was no activity on the database, whereas the
version I saw required a shutdown before this would occur.

o  No support for raw devices - They claim some form of raw i/o (on a 
filesystem??), but all that I saw were synchronous writes.

They claim short development times with their 4GL, and I'd believe them,
it really does look pretty good, kinda Dbase-like.  Perhaps FoxBase might
be something to look into?

Anyway, I think it's probably an ok product, and the 4GL is really nice, but
be sure, if you're on a Unix system, with multiple users of the same 
database, that your application will perform adequately.  

I've only seen Ingres demo'd, so I can't speak to that product.

Rick Butland
(rwb@viusys)

Disclaimer: My dog won't let me speak for him, much less my employer.