[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mason
Subject:    RE: [Mason] WHY precisely httpd up to 12M from previous 4M?
From:       Perrin Harkins <perrin () primenet ! com>
Date:       2000-02-25 23:48:02
[Download RAW message or body]

On Fri, 25 Feb 2000, Paul Leddy wrote:
> can someone give any general to specific details about WHY each httpd goes
> up to 12M from around 4M without mason? preferrably starting out general and
> getting more specific.

Please do read the mod_perl docs that cover this.  This is a mod_perl
issue, not a Mason-specific issue, which is why I pointed other people to
the mod_perl docs. 

The summary of how you can keep the memory size down goes like this:
- Use good programming style, i.e. use strict, so that your variables get
cleaned up.
- Don't import symbols when you can avoid it.
- Follow the standard Perl suggestions for reducing memory useage in the
back of Programming Perl.
- Pre-load as much as you possibly can in the parent process to take
advantage of copy-on-write memory sharing.
- Serve static files and images from a separate server to avoid wasting
your large mod_perl processes on them.

These are all explained in depth by the mod_perl guide.  If you read it
and are still confused, come back and ask for more help.

> Is part of this 8M
> increase due to mod-perl implementation? i.e., does turning on mason also
> turn mod-perl on. if so, then we can blame mod-perl for some of this 8 extra
> M per httpd process, yes? that would be a good start justifying saving our
> mason setup.

First, mod_perl doesn't get turned on and off; it is compiled into your
server.  When you run Perl code thorugh it, the interpreter and the code
stay in memory for the life of the server, so the memory that was
previously outside of Apache in a CGI process is now inside of Apache.  It
isn't really bigger - if you had the same number of CGI processes running 
Mason, the memory consumption would be the same.  

Second, don't run Mason without mod_perl if you need good performance,
especially if there's a database involved.

> if we are doomed, what is the next best tool to use after mason for embedded
> perl. please, no opinions, only fact. %)

All embedded perl tools have this problem because perl, and by extension
mod_perl, has this problem.  You may find that one of them is more
lightweight than Mason (ePerl looks pretty simple), but if you end up
needing the things Mason does for you (caching, parameter wrangling, etc.) 
and re-implement them, you'll probbaly end up using about as much RAM.

One more thing: don't give up!  These problems have been solved well
enough to run many popular sites on mod_perl, and there's no reason to
think it won't work for you.

- Perrin


_______________________________________________
Mason maillist  -  Mason@netizen.com.au
http://netizen.com.au/mailman/listinfo/mason

[prev in list] [next in list] [prev in thread] [next in thread]