The first thought when i read about mod_rails was: “woooooooooooow
,cooool”, but the i read the William Li’s post, and then it became a
“mmm…seems cool…”
How much does mod_rails require instead of mongrel?
I’ve to setup a server with apache and 3-4 rails apps, would be better
going with mongrel or mod_rails ? and, does happen frequently that the
processes are killed and then it takes “a lot” to restart (fcgi like 
)?
Thanks
On Apr 14, 8:57 pm, “Jeremy McAnally” [email protected]
wrote:
It shares code even if I vendor Rails?
It does this to the best of its ability, yes. But it would be most
efficient to use a non-vendor Rails.
William Li wrote:
Let me
know if you’d like to see any further details on the above or have any
other questions.
What would be the verdict for a server running a single application that
gets a couple thousand hits a day?
Would mod_rails be worth it or is mongrel the way to go?
Thanks
On Apr 14, 9:13 pm, Xdmx X. [email protected]
wrote:
The first thought when i read about mod_rails was: “woooooooooooow
,cooool”, but the i read the William Li’s post, and then it became a
“mmm…seems cool…”
How much does mod_rails require instead of mongrel?
I’ve to setup a server with apache and 3-4 rails apps, would be better
going with mongrel or mod_rails ? and, does happen frequently that the
processes are killed and then it takes “a lot” to restart (fcgi like
)?
Thanks
You may also be interested in reading this:
http://www.pervasivecode.com/blog/2008/04/14/why-mod_rails-is-a-really-good-thing-for-light-duty-ruby-on-rails/#comment-5794
This blog post (as well as my replies) explain how the different
Passenger spawners work, and their implications on memory usage.
To make a long story short: the framework spawner that William saw
only lives temporary. It has an idle timeout of 1 hour, so after 1
hour of idling, memory usage will drop again. Furthermore, our soon to
be released “Ruby Enterprise Edition” will allow an additional memory
reduction of 33% on average. (yes, we’re aware of the name, please
bear with us for now 
To William: perhaps it would be a good idea to tweak the spawn servers
timeouts. The timeouts for the framework spawner and application
spawner are 1 hour and 2 minutes, respectively. If you tweak them to a
very low number, and increase RailsPoolIdleTime, then Passenger’s
spawning strategy essentially becomes the same as FastCGI. The spawn
server timeouts are defined as constants in lib/passenger/
spawn_manager.rb (FRAMEWORK_SPAWNER_MAX_IDLE_TIME) and lib/passenger/
framework_spawner.rb (APP_SPAWNER_MAX_IDLE_TIME).
Regards,
Hongli L.
- phusion.nl
Hi, I was wondering, would it be possible to run Ruby scripts on top of
Apache using mod_rails? If this is the case, it may be better to name
the
product mod_ruby.
Great job,
-Conrad
ChessMess wrote:
Mod_Rails is out, so what do you think?
The thoughts that I had for it were
- it shares code base among rails instances–maybe it could also load
some very popular gems, to cut down on the startup time [like
activemerchant, redcloth, etc.) - It looks like it handles static stuffs well–it would be sweet if it
handled all of that on the apache side [inc. asset managed rails 2.0
stuff] so that the rails handlers were freed to serve ‘real’ requests.
Way to go gentlemen.
-R
Roger P. wrote:
ChessMess wrote:
Mod_Rails is out, so what do you think?
Also I assume it ‘takes care’ of running ruby processes like not letting
them grow too large and if they take too long on a request, killing
them?
What if a site is very popular–it might be nice to spawn up several
threads to handle its incoming requests.
That feature would rock.
Another sweet idea would be to patch the GC to use fixed side
[small-ish?] heap chunks so that ruby can reclaim memory more easily on
GC. That would be nice, too.
Take care!
-R
Hongli L. wrote:
You may also be interested in reading this:
Why mod_rails is great for light-duty Rails apps – Pervasive Code
Very interesting. But i’ve some questions 
what would you suggest between the normal ruby (so not yours)+mongrel
and the normal ruby+mod_rails considering the server would run about 2
rails apps with a medium traffic and other 2 apps with a low traffic ?
With more apps a mongrel+mongrel_proxy you’d set some mongrels to one
app, some to another, etc…with instances of 30-40mb each. How would
works with mod_rails? About how much memory would take?
After 1 hour the FrameworkSpawner is stopped and after 2 minutes the
ApplicationSpawner too. How long would take to them to restart? Or
better, when they’re not running, how long would take approximately to
the user to show the first time the page? and what about if the
framework is running and the app not? in that case how much would it
takes?
Thanks
what would you suggest between the normal ruby (so not yours)+mongrel
and the normal ruby+mod_rails considering the server would run about 2
rails apps with a medium traffic and other 2 apps with a low traffic ?
I’m guessing if you are real short on RAM, like in a shared environment,
mod_rails is better [since it collects ruby processes after awhile].
If you use the patched GC, that is.
With more apps a mongrel+mongrel_proxy you’d set some mongrels to one
app, some to another, etc…with instances of 30-40mb each. How would
works with mod_rails? About how much memory would take?
I’m not sure how mod_rails works with firing up ‘multiple spawned
threads’ of the same rails instance, to handle requests. Would be a
nice feature, though.
After 1 hour the FrameworkSpawner is stopped and after 2 minutes the
ApplicationSpawner too. How long would take to them to restart? Or
better, when they’re not running, how long would take approximately to
the user to show the first time the page? and what about if the
framework is running and the app not? in that case how much would it
takes?
Some report 2s, other 5.
Another thought or suggestion I’d have for mod_rails would be to [like
bleak house] auto-install ruby_gc_friendly alongside the normal ruby
[compile it on the fly]. That might be nice. or maybe another gem to
do the same.
Take care!
-R
Actually i’ve a vps with 1 gb of ram, which would run that rails apps
plus a php apps (with a medium traffic) plus the usual stuff which every
common server has (ftp, postfix, mysql, etc)
mod rails would give an easy way to set things up, which is nice. Less
of a headache 
If you did have the load to want more than one processing app, I’m not
sure if you’d [at that point] need mongrel or not.
With just the app down or with the app and the framework?
per app I think. I’m not sure totally, but I think so. Subsequent
requests are fast.
ChessMess wrote:
Mod_Rails is out, so what do you think?
Would be really nice if it handled code changes gracefully as well [i.e.
after an SVN up it automagically restarted the spawned threads).
It probably does.
Thanks for all your work on this!
-R
Roger P. wrote:
I’m guessing if you are real short on RAM, like in a shared environment,
mod_rails is better [since it collects ruby processes after awhile].
If you use the patched GC, that is.
Actually i’ve a vps with 1 gb of ram, which would run that rails apps
plus a php apps (with a medium traffic) plus the usual stuff which every
common server has (ftp, postfix, mysql, etc)
I’m not sure how mod_rails works with firing up ‘multiple spawned
threads’ of the same rails instance, to handle requests. Would be a
nice feature, though.
yes
Some report 2s, other 5.
With just the app down or with the app and the framework?
Another thought or suggestion I’d have for mod_rails would be to [like
bleak house] auto-install ruby_gc_friendly alongside the normal ruby
[compile it on the fly]. That might be nice. or maybe another gem to
do the same.
this would be really nice
ChessMess wrote:
Mod_Rails is out, so what do you think?
Another thought would be
…
as I see it, mod_rails forks off a handler per request, which handler
then dies.
Maybe if it kept the pre-forked handler around for a few requests it
would save speed?
Also it would be nice to have documentation on how and when to use or
not use GC.disable to speed up requests [ex: small-ish requests you may
as well turn the GC off, in case it’s a speed impediment]. I’m not sure
if the GC is a problem or not. Might be worth having the Ruby that is
‘pre-fork’ run GC more frequently so that its forked children don’t have
to, too.
Perhaps variables for tweaking how often the GC is fired.
Thanks again.
-R
On Apr 15, 8:53 am, Roger P. [email protected]
wrote:
The thoughts that I had for it were
- it shares code base among rails instances–maybe it could also load
some very popular gems, to cut down on the startup time [like
activemerchant, redcloth, etc.)
Hi Roger.
This is correct. It can be used to share Gem code memory among
different Rails processes. But it will only have a real effect if you
use our copy-on-write friendly Ruby branch, which will soon be
released.
With kind regards,
Hongli L.
- phusion.nl
On Apr 15, 4:43 pm, Roger P. [email protected]
wrote:
Also I assume it ‘takes care’ of running ruby processes like not letting
them grow too large and if they take too long on a request, killing
them?
What if a site is very popular–it might be nice to spawn up several
threads to handle its incoming requests.
That feature would rock.
This is actually what it already does. It spawns more Rails
dispatchers as traffic increases.
On Apr 15, 9:17 am, “Conrad T.” [email protected] wrote:
Hi, I was wondering, would it be possible to run Ruby scripts on top of
Apache using mod_rails? If this is the case, it may be better to name the
product mod_ruby.
Great job,-Conrad
Hi Conrad.
This is not possible at the moment. Passenger is specialized in Rails
only.
With kind regards,
Hongli L.
- phusion.nl
On Apr 17, 3:15 am, Roger P. [email protected]
wrote:
Would be really nice if it handled code changes gracefully as well [i.e.
after an SVN up it automagically restarted the spawned threads).
It probably does.
Thanks for all your work on this!
Yes we’ve considered this possibility. Unfortunately it’s impossible
to implement this efficiently. In the worst case it will have to poll
every single application source file from time to time. We figured
that it’s just easier and more efficient to tell the user touch tmp/
restart.txt.
On Apr 15, 9:06 pm, Xdmx X. [email protected]
wrote:
Hongli L. wrote:
You may also be interested in reading this:
Why mod_rails is great for light-duty Rails apps – Pervasive Code…Very interesting. But i’ve some questions
Hi Xdmx.
Sorry for the late reply, we’ve been getting swamped with work lately,
and I haven’t had time to reply until today.
what would you suggest between the normal ruby (so not yours)+mongrel
and the normal ruby+mod_rails considering the server would run about 2
rails apps with a medium traffic and other 2 apps with a low traffic ?With more apps a mongrel+mongrel_proxy you’d set some mongrels to one
app, some to another, etc…with instances of 30-40mb each. How would
works with mod_rails? About how much memory would take?
I suggest you to not do anything. Passenger handles all that stuff
automatically. If site A is having more traffic, then Passenger will
spawn more dispatchers for that site. If B is having more traffic,
then Passenger will spawn mnore dispatcher for that site. If traffic
decreases then Passenger will clean up dispatchers.
The point of Passenger is to relieve you of administrative overhead,
like managing Mongrel instance numbers.
After 1 hour the FrameworkSpawner is stopped and after 2 minutes the
ApplicationSpawner too. How long would take to them to restart?
Or
better, when they’re not running, how long would take approximately to
the user to show the first time the page?
That depends on a number of factors. By far the largest factor in
startup time, is disk I/O. Ruby on Rails consists of hundreds of
little files, and startup time on a cold start is dominated by disk
seeking performance.
On my laptop, a cold start takes about 7 seconds. A warm start
(without FrameworkSpawner/ApplicationSpawner running) takes about 2
seconds because disk I/O bottlenecks are eliminated. Some people have
reported a cold startup time of 25 seconds, but that really depends on
the system’s CPU load and I/O load.
and what about if the
framework is running and the app not? in that case how much would it
takes?
If the FrameworkSpawner is running, then spawning time will decrease
significantly. The framework will not have to be loaded at all - only
the application code will have to be loaded. How long that takes
depends on the application though. A “hello world” application starts
almost immediately if FrameworkSpawner is already running.
With kind regards,
Hongli L.
- phusion.nl
On Apr 17, 7:10 pm, Roger P. [email protected]
wrote:
Another thought would be
…
as I see it, mod_rails forks off a handler per request, which handler
then dies.
This is actually not correct. Spawning and forking is slow, so we keep
a pool of spawned Rails handlers around, and we reuse them as much as
we can.
Maybe if it kept the pre-forked handler around for a few requests it
would save speed?
We already do this.
Perhaps variables for tweaking how often the GC is fired.
Thanks again.
Our Ruby branch actually provides this information. Please stay tuned
for the release.
Perhaps variables for tweaking how often the GC is fired.
Thanks again.Our Ruby branch actually provides this information. Please stay tuned
for the release.
Rock on. Thanks for doing this so the rest of us don’t have to.
As noted–I assume it kills processes if they take too much time or
begin to use too much RAM [maybe could run ‘GC.start’ on them first
before killing them for consuming RAM, though that maybe wouldn’t hurt
too much).
Enterprise Ruby maybe should mess with fixed ruby heap chunk sizes to
allow more RAM to be returned to the OS [?]
Take care.
-R