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

[Chris Nandor <pudge@pobox.com>]

At 12:59 -0700 1999.09.28, madame philosophe wrote:
>There seems to be a lot of talk/pressure of going into web app servers
>because the performance is allegedly better than writing straight Perl
>scripts. Is this really true?

Absolutely not.  Depending on your definition of "straight Perl scripts,"
of course.  As Creede notes, CGI can be slow.  So don't use CGI!  Use
mod_perl, FastCGI, Velocigen, ActiveState's PerlEx, etc.  These all work
like "app servers", some better than others.  CGI has a few problems these
all solve in one way or another:

* Perl CGI scripts have to compile and execute each time they are called
(which means that if you use a lot of modules, or have initialization code
that takes a long time to run, you get that performance hit every time the
CGI is run)

* Perl CGI scripts cannot keep persistent connections (so if you connect to
a database, you need to redo that connection, opening and closing it, each
time the CGI is run)

* Perl CGI scripts need a separate interpreter for each time they are
called (so if you have a dozen copies running at once, you eat up a lot of
system memory)

The solutions above keep Perl programs in memory, compiled an executed and
ready to go, so you can keep persistent database connections open, and you
don't worry about startup time.  Some use a new interpreter for each one;
some embed the interpreter in another process; some do other magic.

Which should you use?  If you use Windows, PerlEx is likely a good choice.
mod_perl is the way to go if you already use Apache.  I use FastCGI because
that is the best solution available for Netscape Servers, which is what I
use at work.  I don't know much about Velocigen.  There are likely others
(I've seen an nsapi_perl, which is similar to mod_perl for Netscape
Servers).

They are all very fast solutions.  Anyone who tells you that app servers
are faster than Perl, without qualifying that as being "Perl CGI," doesn't
know what they are talking about.  Perl using the above products, or
similar methods, is just as fast, and usually much faster, than the app
servers out there.


>I am quite skeptical because every 3 months there is a new technology
>that is supposed to make everything better faster, whatever. And from
>what I can tell the API stuff isn't open, but proprietary, which just
>means to me that it is a last ditch effort to distract people from the
>openness of Perl, and charge people money for something they can get for free.

FastCGI is free in theory (the protocol is open), but the only people that
offer it for Netscape charge money for it.  mod_perl is free.  I believe
PerlEx and Velocigen are proprietary.


>Some of us are Mac, some are PC, some are UNIX in my group. One person
>in particular is looking at PerlScript, which seems to be the evil
>side's rendition of Perl. (see http://www.perlscripters.com).

Not at all.  PerlScript is simply a Perl ASP engine made by ActiveState.
It uses the same perl.dll the perl.exe uses, so it should not differ from
ActiveState's perl.exe in any significant.  At least, that is my
recollection of what Dick Hardt (ActiveState's head honcho) said about it
on another list.  It is what you would want to look into using if you are
forced to do ASP.  :)

-- 
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])


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