SPUG: mod_perl

[John Cokos]

Cody,

> One reason I was leaning away from FastCGI is that it still works on a
> seperate process model, 

That's exactly the reason fastCGI is the better solution.  A busted program
(or a bad programmer) can't take down your webserver (and all of your
client's domains).  It's a much safer, more protected environment.

> and cannot take advantage of in the http server
> database connection pooling the way you can with the Apache::DBI module in
> mod_perl.

Sure it can, if your code is tight.   The way we set it up is to open and
close the db connections outside of the fastCGI loop.  Each fastCGI process
pools it's memory with a common shared compiled base in memory, all sharing
the same connection.

John


========================================
  John Cokos, President / CEO: iWeb Inc.
  http://www.iwebsys.com
  jcokos at ccs.net
========================================

----- Original Message ----- 
From: "Aryeh "Cody" Sherr" <asherr at cs.unm.edu>
To: "John Cokos" <jcokos at ccs.net>
Cc: "Alex Algard" <algard at sounddomain.com>; <spug-list at pm.org>
Sent: Friday, July 21, 2000 1:35 PM
Subject: Re: SPUG: mod_perl


> 
> One reason I was leaning away from FastCGI is that it still works on a
> seperate process model, and cannot take advantage of in the http server
> database connection pooling the way you can with the Apache::DBI module in
> mod_perl.
> 
> Cody
> asherr at cs.unm.edu
> 
> On Fri, 21 Jul 2000, John Cokos wrote:
> 
> >>> 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/