Re: [MacPerl] Web application servers and the future of Perl

[Sean Kamath <kamath@pogo.WV.TEK.COM>]

This gets off topic, but what the hell.

[In a message on Tue, 28 Sep 1999 16:19:42 PDT,
	""Creede Lambard (Volt Computer)"" wrote:]
>As I understand it, one of the main reasons you would use an app server is
>that if you run standalone applications, you're opening a new instance of
>the Perl interpreter every time someone calls a page that calls a script.
>It's not much of a leap of logic to see that if you have a high- or even
>medium-traffic web site, you're going to be running a LOT of Perl
>interpreters and your performance is gonna drag.
>
>OTOH if you use an app server, it will open up your script as a thread
>inside Apache, IIS or wherever, which is much more efficient and much
>faster.

use FastCGI for Apache.  This allows you to start the perl interpreter
once.  I don't know how it handles threads, of if it does.  But it
definately speeds things up.

>As for PerlScript, nothing really evil about it, even if Microsoft did foot
>part of the bill for its development (which I think they did). It's a way of
>offering Perl for use as a browser-scripting language, similar to JavaScript
>or VBScript. 

Using some server side includes (which is what Active Server Pages
are.   Been around a lot longer than Active Server Pages.) can
obviousely speed up processing, as can doing something as psychotic
(but useful) as compiling in a perl interpreter to Netscape (been
done, as a plugin).  Talk about speed improvements.  However, SSI's
are terrible security holes.  So are CGI programs.

If you want fast CGI-only programs, why not use perl as the web
server? :-)

>Anyone on the list who cares to contradict me, feel free to do so -- as I
>said, this is what I've heard and read, not what I've actually done.

Oh, no contradiction. Just your normal "well, it depends".

Sean

# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org