On Wed, 12 Apr 1995 16:09:11 GMT Mike Belshe said:
>Kyle Parrish ([log in to unmask]) wrote:
>: Birket,
>: Here is my plan.  A professor links to my Web site.  Uses a login screen
>: to get access to another screen.  This screen allows him/her to run
>: reports, with the data coming back to his/her screen.
 
An opinion shared by Eric Shubert of Notre Dame and myself.
 
>: Now, here are the three possible ways I see to do this, but I don't
>: understand what each would require, so I am putting it out here for input.
>:    1)  PC based Web server.  Could I use Powerbuilder, or some other
>: ODBC compliant application to perform my calls to Image?
 
Ick :-)  fork()/DBOPEN() overhead plus the ODBC overhead (personal opinion).
 
>:    2)  UNIX based Web server.  Can I still use ODBC compliant apps to
>: make my calls to Image?
 
Ditto #1.
 
>:    3)  3000 based Web server.  I got some info that I am digesting now,
>: but I need to know what the performance load is on the 3000.
 
That depends on how you implement the interface.  Authentication is a must,
which adds some overhead.  There is the Netscape secure transactions, and
there are some "plug and go" client authentication tools from Univ of Del
that exploit the "launch and go" viewer/helper-applications in clients so
that they submit a customized filetype to the client, launching the
authentication program on the client.
 
>While I haven't done extremely scientific benchmarking on the HP3000
>server, I did do some simple tests making lots of simultaneous
>requests to a 3k web server and measuring the time for it to process
>them, and comparing it to the 9k doing similar tasks.  I expected
>the 3k to have a serious performance hit due to the costly fork().
>However, the impact wasn't too bad.
 
This is encouraging :-)
 
>The second comment I would make is that if you are worried about overloading
>a machine with these types of database requests, you might be using
>the wrong interface.  WWW was not designed or optimized for this type of
>traffic.  While WWW does provide a nice, OPEN interface, it is not
>really the best interface for database queries.  In my opinion, WWW
>database front-ends should be primarily used when data is needed for
>anonymous, public access.  Otherwise, if you have heavy traffic into
>a database, you probably ought to be using the client-servers and odbc
>available with most all databases today rather than WWW. That should
>give you the best performance.  Hope that makes sense.
 
I disagree here, it makes the client overly complex and the execution is at
the whim of the SQL optimizer on the host.  With the Web form, we take a giant
step backwards in terms of the host application -- you receive a blob of data
from a form, and you either process it and say all is well, or you return the
error condition.  Essentially you're using the Web form as a smart VPLUS form.
I personally am not overly-enthused about having Joe User getting update
access to a database on the host without me having some control over what sort
of transactions are taking place, not to mention the complexity.
 
The Web form/gopher search/whatever model is the utmost simplicity and the you
are only getting transaction data for a predefined transaction.  With ODBC,
you have less control over the nature of the transaction at hand.
 
[\] Jeff Kell, [log in to unmask]