SPUG: mod_perl

[Alex Algard]

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