daniel at rimspace.net
Wed Sep 13 20:43:49 PDT 2006
"Andrew Speer" <andrew.speer at isolutions.com.au> writes:
> On Thu, September 14, 2006 11:35 am, Scott Penrose wrote:
>> Hey Guys
>> .. snip ..
>> The sort of topics I would like to cover are:
>> * Why should you use mod_perl
>> * Why should you use mod_perl2
>> * Why should you not use mod_perl
>> * Processing Parameters, Environment Variables and Headers - in
>> Content and Filter handlers (and other stages)
> I am from Adelaide, so was not able to make the meeting. It may have
> been covered, but one of the issues I seen when using mod_perl(2) is
> memory usage per connection.
> When using Apache with mod_perl processes can easily grow to 10M+ (or
> more, depending on the app).
Only 10MB? Lucky you. One of my clients has around 70MB of footprint
from their mod_perl related code.
Also, remember that most of that memory is shared between Apache
instances in a copy-on-write fashion. So, for all that you have the
same 70MB each fork you end up with 2MB of extra memory used each time.
The overall memory figure can be *very* misleading, and it is very hard
to get an impression of the level of private memory a Linux binary uses,
because of the way copy-on-write data is accounted.
> If the site/app suddenly becomes subject to a high load Apache will
> spawn more processes to service the load. Unless you have given very
> careful consideration to memory utilisation the server can easily be
> swamped by Apache processes needing more memory than is physically
> available. The server starts swapping and performance suffers badly.
This is true regardless of the code you use on the server, though.
Getting it wrong is more visible if you get the memory use analysis
wrong, but a PHP script that works over 64MB of dynamic data is just at
deadly as a static 10MB from Perl.
> There are ways and means around this problem, but they all seem a bit
> kludgy - front-end proxy servers, multiple Apache servers (Apache with
> mod_perl for dynamic content, straight Apache for static content).
...er, or you could tune your Apache process correctly. That way you
fixed the problem rather than trying to work around it.
> If your main need is content-phase dynamic content (a big part of most
> mod_perl apps) you may want to have a look at lighttpd + fastCGI and
> the CPAN FastCGI module. lighttpd spawns as many Perl FastCGI
> processes and you want, and only sends requests to them if dynamic
> content generations is required - as opposed to Apache, which in the
> "default" mod_perl config will handle both static and dynamic content
> - ie you may have a 10M+ process tied up sending down a JPEG or CSS
Apache also supports FastCGI -- with the original FastCGI module and the
newer (and more free) FCGI module. Both of these give the same benefits
as lighttpd and FastCGI, plus the advantages that mod_perl and other
Apache modules provide.
> If you want to do tricky stuff outside the content generation phase
> then mod_perl is still one of the best/easiest ways to extend Apache
> with Perl.
Yes. I strongly encourage people to use FastCGI for the main content
generation phase -- for both PHP and Perl.
It provides the same advantages as mod_perl in terms of static
initialization and shared memory, gives you (potentially) better control
over the load from the application, and decouples the life cycle of the
dynamic application and the Apache instance.
 The application has other issues, so this isn't entirely the fault
of mod_perl, and it is on a native 64bit platform.
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707 email: contact at digital-infrastructure.com.au
More information about the Melbourne-pm