Message-ID: <31CED352.3630@mail.amsinc.com>
Date: Mon, 24 Jun 1996 10:41:38 -0700
From: Scott Day <scott_day@mail.amsinc.com>
X-Mailer: Mozilla 2.0 (Win16; I)
MIME-Version: 1.0
Newsgroups: comp.lang.smalltalk,comp.lang.objective-c
Subject: Re: VisualWave or WebObjects - speed? performance? (summary)
References: <31C864D7.835@tmfi.com> <Jan-2006960840160001@news.magmacom.com> <4qkbed$e4l@client2.news.psi.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: sday.amsinc.com
Lines: 101
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!swrinde!howland.reston.ans.net!nntp.coast.net!news.kei.com!newsfeed.internetmci.com!in1.uu.net!dns.amsinc.com!
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:39847 comp.lang.objective-c:5307

Mark Murphy wrote:
> 
> Jan@Bytesmiths.com (Jan Steinman) wrote:
> 
> >In article <31C864D7.835@tmfi.com>, Alex Morgan <alex@tmfi.com> wrote:
> 
> >> MarkM@SapphireGroup.com (Mark Murphy) wrote:
> >>
> >> > The problem with both of those products is that they are
> >> >primarily
> >> > CGI-based.  Every request that comes in that involves their
> >> >code forks
> >> > a process to handle the request...
> 
> >You forgot the capital "P". I'm sure it doesn't really fork an OS process,
> >but rather a Smalltalk Process, and Smalltalk Processes are extremely
> >efficient. Compare this to most C-based servers, which must actually fork
> >a real OS process in order to service multiple requests -- talk about
> >paging!
> 
> VisualWave supports all Web servers on VisualWorks-supported
> platforms.  Therefore, VisualWave must use CGI (Common Gateway
> Interface) to have the Web server call out to create a dynamic page --
> there is no other completely Web-server-portable option.
> 
> CGI works by forking an OS process to run a separate program, passing
> in data via a combination of environment variables, program
> command-line arguments, and standard input.  The CGI program creates
> the desired Web page and shoots it back to the Web server via standard
> output.
> 
> VisualWave presumably takes the "thin CGI" approach of having that CGI
> program use IPC to communicate with the running Smalltalk image.  The
> Smalltalk image is presumably using multiple Processes to handle the
> incoming requests, as do most Smalltalk servers.
> 
> However, the limitation here is CGI.  If VisualWave supported NSAPI,
> ISAPI, or FastCGI, performance and scalability would improve by
> avoiding the OS process creation on every page request.  Not that
> there aren't other scalability problems with Web environments in
> general (e.g., HTTP using a different TCP connection for each item
> downloaded on a page).
> 

Although I haven't used VisualWave, I am currently using IBM's VisualAge Web Connection.  
The VisualAge Web Connection has a similar architecture as VisualWave and takes a very similar 
approach in supporting Web applications.  A "thin CGI" program is installed with the HTTP Server.  
Each time a URL is hit to retrieve a Web Connection page, the HTTP server creates an instance of 
the CGI program (as an OS process) which opens a socket to the VisualAge Web Connection server 
image.  The server image is long-running OS process that is listening on a specific TCP/IP port and 
forks a Smalltalk-process for each client request.  I believe that Mark's point is that both Web 
Connection and VisualWave are dependent on a small CGI program that is used to communicate between 
the HTTP server and the Smalltalk server process.  As these products mature, I suspect that both 
will investigate using either the Web Server APIs (NSAPI or ISAPI) or FastCGI since their current 
implementations sacrifice speed for portability by choosing to use CGI.

> >> > VisualWave has further problems, in that it is not
> >> >multithreaded.
> >> > When a request for a VisualWave page comes in, it forks a
> >> >CGI program,
> >> > which signals to a running VisualWorks image to do some
> >> >processing.
> 
> >Duh? "Fork a CGI program?" This is a pretty silly thing to do, when
> >VisualWorks has such excellent socket support already. If this is REALLY
> >the way that VisualWave works, then I think I'll spend a weekend and write
> >something than will blow it away! :-)
> 
> The Web server forks the CGI program, not Smalltalk.
> 

The point here is that both VisualWorks and VisualAge do not take advantage of OS threads and 
therefore a single Smalltalk process cannot take advantage of multiple processors on an SMP machine 
and operating system.  Therefore, the only scaling option for VisualWorks or VisualAge servers is 
to run multiple Smalltalk images (multiple OS processes).

> >Yes, that would explain a certain amount of uninformed bad-mouthing,
> >wouldn't it? :-)
> 
> Actually, it is an informed product comparison.  PageBlazer has its
> own set of limitations (woefully incomplete object model, to name
> one).  I am not even trying to say that PageBlazer will necessarily
> scale better than VisualWave -- only time and experience will tell
> that.  However, the original poster inquired about limitations of
> using VisualWave, and its reliance on CGI is one of them.  Not that
> this is a fundamental limitation in VisualWave itself -- PP-DT could
> create NSAPI/ISAPI/FastCGI gateways in a heartbeat and overcome this
> problem.  But, today, it's a bottleneck.
> 
> Mark Murphy
> The Sapphire Group
> MarkM@SapphireGroup.com
> 
> Makers of PageBlazer(TM) for dynamic Web site development!

I would suggest checking out PageBlazer if you are considering web development for the Windows NT 
platform.  I just saw a demo of the product last week.  They have created a Smalltalk-like 
development environment, with a Visual Basic-like language, for developing web applications.  Their 
server process takes advantage of Windows NT threads and therefore should be able to scale to 
multiple processors without any additional code.  In addition, by taking advantage of the HTTP 
server APIs, they have bypassed the bottleneck of traditional CGI.  It will be interesting to see 
what develops with FastCGI.  If standardized, FastCGI could provide API-like speeds without having 
to code to a specific HTTP vendor's API implementation.

Scott Day
American Management Systems, Inc.

