[Mongrel] Multi apps in one Mongrel instance
ezmobius at gmail.com
Fri Aug 25 12:34:07 EDT 2006
On Aug 25, 2006, at 9:22 AM, Kirk Haines wrote:
> On 8/25/06, Jarkko Laine <jarkko at jlaine.net> wrote:
>> No offense, Jean-Eric, but you already asked this two weeks ago 
>> and got 7 responses, including one from Zed himself .
>> The answer: You can't do that as long as Rails is not thread-safe, in
>> other words not any time soon.
> Some time ago on ruby-talk there was a little discussion about using
> fork() as a sort of crude mark and sweep heap manager.
> The basic idea is that on certain OSes, fork() can be very, very fast
> because a copy-on-write is done on the memory image. Disable GC as
> soon as the fork is completed, do your thing, and let the forked
> process die.
> The memory of this discussion jumped out at me the other day when
> someone was asking about Mongrel and multiple Rails requests.
> I'm not going to do the work because I have more than enough other
> work in progress right now, but here's the idea:
> Change Mongrel and the Rails handler so that one has the option of
> forking instead of spawning a new thread to handle the request. It
> might be a usably fast way to get multiple Rails requests out of a
> single Mongrel. On my test server (a pretty modest AMD based box
> running a 2.4 Linux kernel), I can fork a little over 200 7Mb
> processes a second in a simple test.
> Kirk Haines
This is certainly an interesting idea but the problem I see with
this is ActiveRecord's database connection hates fork. Most of the
time if you use fork in a rails app you will immediately get the
"Mysql server has gone away" error. THere is a workaround you can use
but its not pretty.
# whatever code you wanted to do in the fork
# but make sure the last thing you dlo in the fork is this:
Kernel.exec "echo -n"
The trick being Kernel.exec "echo -n" as the last thing you do in
the fork. This keeps the database connection from being dropped on
the floor for some odd reason.
More information about the Mongrel-users