SPUG: mod_perl

John Cokos jcokos at ccs.net
Fri Jul 21 15:16:32 CDT 2000


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