Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!arclight.uoregon.edu!news.sprintlink.net!news-peer.sprintlink.net!news.mathworks.com!news.pbi.net!cbgw3.lucent.com!nntphub.cb.lucent.com!alice!allegra!akalice!baldy.research.att.com!user
From: pereira@research.att.com (Fernando Pereira)
Subject: Re: linking a Prolog program into an HTTPD
X-Nntp-Posting-Host: baldy.research.att.com
Message-ID: <pereira-1111962316330001@baldy.research.att.com>
Sender: news@research.att.com (netnews <9149-80593> 0112740)
Organization: AT&T Research
References: <55qu7g$31g@wuff.mayn.de> <55t9ap$at4@sol.sun.csd.unb.ca> <565tbi$alm@mulga.cs.mu.OZ.AU>
Date: Mon, 11 Nov 1996 22:16:33 GMT
Lines: 35

In article <565tbi$alm@mulga.cs.mu.OZ.AU>, lee@cs.mu.OZ.AU (Lee Naish) wrote:
> In article <55t9ap$at4@sol.sun.csd.unb.ca>,
tarau@clement.info.umoncton.ca (Paul Tarau) writes:
> > In article <55qu7g$31g@wuff.mayn.de>,
> > David Sedlock  <das@nicklas.franken.de> wrote:
> > 
> > >executable every time the application is called. As it stands, the
> > >response time of a Prolog application over the net is likely to
> > >reinforce the general opinion that Prolog is too slow for serious use.
> 
> > A server-side Prolog is important as a way to keep (possibly persistent)
> > `state'. On the other hand, the performance issue is more tricky.
> 
> <multiple expletives deleted> hasn't anyone noticed that THE NETWORK might
> be just a little bit more important than how fast a Prolog process starts???
> I just pointed my browser at Paul's page to check out the response time.
> After several tries all I got was "A NETWORK ERROR HAS OCCURRED"...
> If and when I manage to connect I have a sneaking suspicion that the network
> bandwidth and latency might be a trifle more important than the time taken
> to start up a reasonable Prolog system on a modern machine.
You are looking at it from single client's perspective, which is fine for
measuring response latencies for single connections to a lightly loaded
server. But if you look at it from the server's perspective, those
relatively costly process startups soon add up to real load if the server
is popular. And an overloaded server is one that eventually slows down to
a crawl, times out or runs out of resources, creating the kinds of
problems you saw accessing Paul's pages. 

In any case, Don Ferguson and others pointed out that the right way for
serving the Web with complex software applications, both for perfomance
and maintainability reasons, is to create a lightweight CGI stub that
connects to a persistent version of the application. That's often how
databases are used for Web service, eg. Oracle's Web server tools do not
run the database system directly, but instead connect to the standard
Oracle server.
