>Date: Thu, 13 Apr 1995 01:00:27 EDT
>Reply-To: Jeff Kell <[log in to unmask]>
>Sender: HP-3000 Systems Discussion <[log in to unmask]>
>From: Jeff Kell <[log in to unmask]>
>Organization: University of Tennessee at Chattanooga
>Subject: Re: Query Image from Netscape -Reply
>In-Reply-To: <[log in to unmask]>
>Lines: 64
 <snip>
 
(I think this is Mike Belshe talking?)
>>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.
 
(this is Jeff Kell talking)
>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.
 
Eric Schubert agrees with Jeff:
-------------------------------
Our 992 performed 24,000 TCP/IP socket connections (avg 20 data base queries a
minute all day and night long) to 2200 individual students (about 13,000 total
data base queries) while servicing **260** hp logon sessions banging data in
etc.  In addition, we had about 30 Telnet users (my telnet server) on while
all this was happening.  The Gopher data base response queries averaged
between 1 and 6 seconds all day long.  Sessions didn't notice that
hundreds of individuals (at a given time period) were getting access to their
data from data base queries.  Total CPU time never exceeded 9% of
system for Gopher data base queries.
 
When you have to explode thousands of individual user queries over a
network, you better pick stateless methods, i.e., WWW.  Also, because we have
a robost authentication service (AFS) as the front end, it helps a lot.  But I
would think an htACCESS list would work just as well as our AFS frontend.  The
WWW htACCESS list performs a compare and match on a list of user
names/passwords when authenticated.  Speculation is not comforting, I know.
 
But our system IS in production and puts HP data on thousands of desktops all
over campus (~4000).  Never had to upgrade anything.  Before gopher, we
average 75% of system capacity.  After Gopher, we still average 75% of system
capacity (laser rx stats).  But we put HP data on 4,000 desktops.  Almost
sounds like ghosts.  The secret is the stateless methods (WWW), avoid
logons/terminal access like the plague.
 
Of course, if 2,000 requests come in all at once, we'll choke.  You have to
manage that end of it also.
 
BTW, DOE (Dept of Energy) is using Web servers now as part of their
new funded research online system.  They use a Web URL with an SQL query
so researches can check on their DOE proposals.  Notre Dame is one of four
Universities on the beta trial period.  The world is turning to Web.  Don't
miss it!
--------------------------------------------------------------------
Eric J. Schubert                 Administrative Information Services
Senior Data Base Analyst         University of Notre Dame, IN USA
 
Email:            [log in to unmask]
Phone:            (219) 631-7306
World Wide Web:   http://www.nd.edu/~eschuber