SPUG: mod_perl

[Alex Algard]

I'm curious to hear more about the security holes... that's news to me. Also
just be aware of the pros and cons of mod_perl and FastCGI - they are
entirely different beasts, and they are both useful.

The usual argument in favor of FastCGI is that it's restricted neither to
Perl nor to Apache. Also, FastCGI processes are not as integrated with httpd
as mod_perl, which is supposed to be more stable.

We chose mod_perl, b/c we're staying with Apache and Perl. If you use
mod_perl, unlike FastCGI you don't need to rewrite your code with
Apache::Registry, you don't need to restart every time a script is modified,
you don't need to rebuild Perl with sfio to make it work, and the number of
processes handling requests is dynamically determined rather than static.
Also, the beauty of mod_perl is in its integration with Apache; it's much
more than just a persistent Perl interpreter. You can customize every stage
of request/response for Apache. Of course, there's also a ton of talented
ppl working on improving mod_perl and creating modules for it.

________________________
Alex Algard
SoundDomain.com | CarDomain.com | WhitePages.com
425-820-2244 x11 | fax: 425-820-5951
algard at sounddomain.com


> -----Original Message-----
> From: John Cokos [mailto:jcokos at ccs.net]
> Sent: Friday, July 21, 2000 1:17 PM
> To: Alex Algard; spug-list at pm.org
> Cc: Aryeh "Cody" Sherr
> Subject: Re: SPUG: mod_perl
>
>
> >> we have noticed a performance increase of almost
> > 100x in going from cgi to mod_perl.
>
> That's nothing ... move it to fastCGI, and it'll really smoke,
> on average twice as fast as mod_perl, and no security holes.
>
> John
>
> ========================================
>   John Cokos, President / CEO: iWeb Inc.
>   http://www.iwebsys.com
>   jcokos at ccs.net
> ========================================
>
> ----- Original Message -----
> From: "Alex Algard" <algard at sounddomain.com>
> To: <spug-list at pm.org>
> Cc: "Aryeh "Cody" Sherr" <asherr at cs.unm.edu>
> Sent: Friday, July 21, 2000 12:12 PM
> Subject: RE: SPUG: mod_perl
>
>
> > > I'd like to hear from anyone who is using it in spug land,
> and what their
> > > experiences were like. I'd be especially interested in
> hearing from anyone
> >
> > Overwhelmingly positive. We've set up mod_perl on two of our
> servers so far,
> > and in our benchmarking, we have noticed a performance increase
> of almost
> > 100x in going from cgi to mod_perl. We are using
> Apache::Registry; if you
> > use mod_perl handlers for the request stage, you can squeeze
> out marginally
> > better performance. Apache::Registry is probably the best way to get
> > started. Existing cgi code should run fine under mod_perl, except for
> > sloppily coded scripts.
> >
> > Just another few random notes, based on our experience...
> >
> > Set up a separate development server with just a single process
> - this will
> > make debugging a lot easier whenever you come across the inevitable data
> > persistence issues. Also don't forget to disable keepalive (if you have
> > separate mod_perl and image servers), or each client will lock
> up an Apache
> > process throughout the keepalive instead of releasing it after a few
> > milliseconds (also, as we experienced, it's difficult to debug a
> > single-process Apache in a multi-user environment if keepalive is on).
> >
> > Memory tends to be the bottleneck to monitor with mod_perl.
> Until Apache 2.0
> > comes out, to avoid running out of memory if you have a well-trafficked
> > site, you should place static content/cgi scripts and mod_perl
> on separate
> > servers, and be sure to take advantage of memory sharing for as
> many modules
> > as possible. If you notice that many requests are taking more than a few
> > milliseconds (after disabling keepalive), you probably have modem users
> > tying up the Apache processes. In that case, look into using a
> proxy server
> > such as Apache's mod_proxy (we're planning to use it...); stay away from
> > Squid. Most importantly, make good use of perl.apache.org --
> there's a ton
> > of good info there.
> >
> > ________________________
> > Alex Algard
> > SoundDomain.com | CarDomain.com | WhitePages.com
> > 425-820-2244 x11 | fax: 425-820-5951
> > algard at sounddomain.com
> >
> >
> > > -----Original Message-----
> > > From: owner-spug-list at pm.org
[mailto:owner-spug-list at pm.org]On Behalf Of
> > Aryeh "Cody" Sherr
> > Sent: Friday, July 21, 2000 10:34 AM
> > To: spug-list at pm.org
> > Subject: SPUG: mod_perl
> >
> >
> >
> > We have been casting around at work trying to find ways for our perl
cgis
> > to run faster. My attention has repeatedly turned to mod_perl. And
> > yet, I have not been able to find anyone to speak with who is using it
in
> > a production environment.
> >
> > I'd like to hear from anyone who is using it in spug land, and what
their
> > experiences were like. I'd be especially interested in hearing from
anyone
> > who has refactored existing .cgis to run under mod_perl in a heavy
traffic
> > site. Also, there are various levels of mod_perl buy-in: PerlRun,
> > Apache::Registry, and fullblown mod_perl code. Any comments on those?
> >
> > Thanks in advance.
> >
> > Cody
> > asherr at cs.unm.edu
> >
> >
>
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >      POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
> >       Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
> >   Replace ACTION by subscribe or unsubscribe, EMAIL by your
Email-address
> >  For full traffic, use spug-list for LIST ; otherwise use
spug-list-digest
> >   Seattle Perl Users Group (SPUG) Home Page:
http://www.halcyon.com/spug/
> >
>
>
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>      POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
>       Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
>   Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
>  For full traffic, use spug-list for LIST ; otherwise use spug-list-digest
>   Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/
>
>
>


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For full traffic, use spug-list for LIST ; otherwise use spug-list-digest
  Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/