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