SPUG: mod_perl

John Cokos jcokos at ccs.net
Fri Jul 21 17:26:19 CDT 2000


The very fact that mod_perl allows you (depending on which Apache:: modules you have installed)
to get right into the guts of apache is a security hole.

Assuming, of course, your personal coding skills and eye for safety 
and detail are top notch, you have no control over what the bozo
behind you (or next to you), or the next sysadmin does to your code
or to apache itself.

FastCGI, operates on it's own little island, protected from the server,
and protecting the server as a side benifet.  As it serves only one purpose
(to be fast), unlike mod_perl which is fast AND allows for "guts" programming
of apache, fastCGI is inherently quicker, more stable, and IMO, the only
real choice if pure performance is your goal.

As an aside:
    Turbo Linux Server (smallest, fastest kernel going), running Zeus instead
    of apache (Zeus is $$, but built totally for speed), and fastCGI....
    I'd put that combo up against almost any server combo, pound for pound,
    a true dynamo.

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: "John Cokos" <jcokos at ccs.net>
Cc: "Aryeh "Cody" Sherr" <asherr at cs.unm.edu>; <spug-list at pm.org>
Sent: Friday, July 21, 2000 3:04 PM
Subject: RE: SPUG: mod_perl


> 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/





More information about the spug-list mailing list