SPUG: mod_perl

[Aryeh "Cody" Sherr]

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/