From: ara.t.howard@...
Date: 2007-02-04T16:41:31+09:00
Subject: Re: Using fork to conserve memory

On Sun, 4 Feb 2007, Daniel DeLorme wrote:

> ara.t.howard@noaa.gov wrote:
>> you realize that this is __exactly__ what running rails, or any cgi, under
>> fastcgi does right?
>
> No, fastcgi creates a bunch of worker processes and loads the full rails 
> environment in EACH of them. That means a lot of memory (30+ MB for each 
> process) and a long initialization time (2+ seconds for each process).

yes, i realize that.  still, the concept is to start the workers before the
request comes in so startup time is minimized.  it's true that memory is used
by each process but the number of processes can be configured.

>
> What I'm talking about is loading the large environment once and THEN
> forking off worker processes that don't need to go through the expensive
> initialization sequence. It seems like an obvious idea and rails is not the
> only framework with a large footprint, so *someone* must have done something
> like this already.
>

that would be fairly difficult - consider that the all open file handles, db
connection, stdin, stdout, and stderr would be __shared__.  for multiple
processes to all use them would be a disaster.  in order to be able to fork a
rails process robustly one would need to track a huge number or resources and
de/re-allocate them in the child.

any decent kernel is going to share library pages in memory anyhow - they're
mmap'd in iff binary - and files share the page cache, so it's unclear to me
what advatage this would give?  not that it's a bad idea, but it seems very
difficult to do in a generic way?

regards.

-a
-- 
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama