In article <[log in to unmask]> [log in to unmask] (Jerry
Bostick) writes:
>>On Sat, 25 Mar 1995 14:23:58 -0600 Richard Gambrell said:
>>>BTW Any of you 4-gl providers interested in making the hp3k web server
>>>have friendly access to Image? This sounds to me like a market
>>>opportunity...
>>
>[snip]
>>
>>I'm a little apprehensive about the startup/load/DBOPEN/etc overhead
 
>One approach we have used is to write a db server listner process
>which is listening (via message file) for db requests.  This is
>a sleeper process which is always running.  It only opens the image db
>at program start up.  When the user's browser posts a form, a cgi "c"
>program fwrites the info to the message file and the listener
>process returns the data via a second message file to the cgi prog.  It
>in turn builds an html page on the fly and returns it to the web browser.
 
 Myth #1 - DBOPENS are bad and to be avoided at all cost.
 
 I would argue that the above message file system might take more overhead
than the DBOPEN it was trying to avoid because you insert a file layer
between source and destination DBGET's.
 
 We took a different approach.  We ran SPT (system performance tool) and
found only the FIRST DBOPEN was the hog, the second DBOPEN on the same data
base was clock'd at a few millisecs.  Our port listener deamon simply opens
the IMAGE data base(s) and keeps them open until the service is terminated
(keeps that xxxxxGB file active).  Our "forked" processes perform their own
dbopen, etc. with very little overhead, because the data base is always open.
 
 We watch our load paths and don't glob in tons of junk we don't need.
 
 We can process an entire grade history report (50 to 150 IMAGE reads from
about 5 sets) in .333 CPU seconds and typically at 1 second wall time for
EVERYTHING - connection, response, close.
 
We don't have file open logging turned on either.  That might make a big
difference.
--------------------------------------------------------------------
Eric J. Schubert                 Administrative Information Services
Senior Data Base Analyst         University of Notre Dame, IN USA
 
Email:            [log in to unmask]
World Wide Web:   http://www.nd.edu/~eschuber