At 10:30 AM 28/3/95 EST, Jeff Kell wrote:
>I'm a little apprehensive about the startup/load/DBOPEN/etc overhead
>with this though, but I don't see any obvious way to clean it up given
>that the Web server will create a new instance of the cgi-bin process
>for each transaction.  Maybe IPC files(?)...
 
Yes, the overhead would be significant, and IPC files are certainly one way
that would be easy to accomplish the task.  It needn't necessarily be mapped
to $stdlist & $stdin, though.  Bear in mind that the Request file could  be
shared by any number of processes spawned by the Web server, while the Reply
file needs to be unique for each Request.  Ergo, the program handling the
DBrequests will either have to derive the Reply file name (ie "RY" +
<requestor pin>) OR the reply file name will need to be included in the
request.  If the program handing the DBrequests is not spawned by the Web
server itself, then the IPC files will need to be in permanent directory
space, so some housekeeping will be necessary to keep the environment clean.
The whole point though is to minimize the program startup and DBOPEN
overheads.
 
Another, means to accomplish the same task is to use networking ipc.  Even
if the web server was on a unix box ("Boo! Hiss!"), the dbrequests can be
made across to the HP3000.  John Sullivan was demonstrating just such a
mechanism I believe at the CSL booth at the Denver Interex conference.  The
fact the web server could be on the 3000 wouldn't change the technique, just
the names.
 
The real problem, as I see it, comes from single threading the DBrequest
process program.  A single database reqest can take a considerable time,
which is fine for that requestor, but all other requests are queued awaiting
processing.  A type of arbitrator or some contrived method is necessary to
handle multiple requests coming in.  In unix, we'd simple fork() producing
another process.  But even on MPE/iX 5.0, fork()-ing still appears to be a
large overhead and slow.  I don't know the effect with open databases...
does it still work?  Any ideas on how to improve the concurrency?
----
Jim "seMPEr" Wowchuk           Internet:    [log in to unmask]
Vanguard Computer Services     Compu$erve:  100036,106
 _--_|\                        Post:        PO Box 18, North Ryde, NSW 2113
/      \                       Phone:       +61 (2) 888-9688
\.--.__/ <---Sydney NSW        Fax:         +61 (2) 888-3056
      v      Australia