I think that I might give it a try out.
--
Posted via http://www.ruby-forum.com/.
- Faster than mongrel, on par with thin
- Thoroughly tested and profiled for stability
- Two lines of installation and a small snippet of code in apache config
- Free to use and completely open source
I would say this is an exciting day for rails.
I have to reconfigure my capistrano scripts to reflect this, but i like
what I see.
I added a .htaccess file to my app root containing:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^$ public/ [L]
RewriteRule (.*) public/$1 [L]
</IfModule>
So now i can drag and drop the whole app into the folder without
pointing the root to the public folder (one extra step less).
I really like it.
We do not have a single reason now to envy PHP or Asp.Net, when it comes
to deployment.
I am full of cheers...
lets see, what rubinius does with with such inspiration.
John,
Would you mind explaining what you mean? If you still have to set up a
virtual host in your apache config, what step are you saving since you
have to define DocumentRoot? If you are talking about being able to use
the same domain and have the Rails app appear "under" it, such as
wouldn't that require something like a prefix in the app so your
generated routes would be correct? I'm thinking of the situation where
you have to apps living next to each other like
www.mydomain.com/rails_app_1
www.mydomain.com/rails_app_2
and how you'd need a prefix in both apps for the routes to work.
I might be missing something, though. I'd really like to be able to
have many apps live under one domain easily.
Thanks,
Phillip
Best regards,
Bill
anyone who has tried it... can post some reviews?
Testing with a fresh install of redmine-0.6 on RHEL5 w/ Apache 2.2.8,
Mongrel 1.1.4, ruby 1.8.6 PL114, passenger 1.0.1 we've noticed a few
things:
1) The app fired up in a Mongrel instance uses 35MB RES.
2) The app fired up with mod_rails loads an ApplicationSpawner (40MB
RES), a rails instance (39MB RES), and a FrameworkSpawner (25MB RES).
The FrameworkSpawner only seems to run if you have Rails gems frozen in
the app.
3) If the app hasn't been hit within the RailsPoolIdleTime the
ApplicationSpawner/RailsInstance/FrameworkSpawner all die away. The next
hit takes a few seconds for these to load again (remind you of
something?).
At this point for shared clients we're still recommending Mongrel
clusters over mod_rails (Mongrels on average take less memory out of
your quota and are 'always on') but are happy to offer both. Let me
know if you'd like to see any further details on the above or have any
other questions.
Cheers,
~William
http://www.hostingrails.com
http://www.hostingrails.com/mod_rails_hosting
~William
http://www.hostingrails.com
DyingToLearn wrote:
> @William,
>
> What about those with many different rails apps, all with low volume?
> So for example, if I had 10 apps, (each with <5 visits per day) I
> would need 10 mongrels. Using you example numbers, that is 350MB.
> However, if I used mod_rails, and I had the same 350MB available,
> would it share the available memory between only the running apps?
> That would (in theory) make the running apps faster, after the initial
> slow requets.
>
> Thanks,
> Paul
>
> On Apr 13, 3:39�am, William Li <rails-mailing-l...@andreas-s.net>
--
Posted via http://www.ruby-forum.com/.
Main problem I have right now is that static content (images, js files)
seem to be taking 2 to 3 longer to download than when I was using
Apache/Mongrel (measured using firebug's net tab).
Anyone else seeing an issue with static content download speed?
Could you have a look at
http://groups.google.com/group/phusion-passenger/browse_thread/thread/e6dc620227ed7b4c
and repeat your experiment ?
Passenger is designed to work best with GC enabled ruby patch
http://izumi.plan99.net/blog/index.php/2008/01/14/making-ruby%E2%80%99s-garbage-collector-copy-on-write-friendly-part-7
from the memory point of view. I'll need to convince Hongli/Ninh to
make that information a bit more clear :)
With GC patch, each rails application can share the framework code in
memory and that results in huge memory savings.
-Pratik
--
Cheers!
- Pratik
http://m.onkey.org
--Jeremy
--
http://jeremymcanally.com/
http://entp.com
Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)
Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com
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
The thoughts that I had for it were
1) 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.)
2) 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
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!
> 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
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 :)
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)
> 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
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.
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
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.
Hi, thanks for every answers :)
Just the last one.
What happen if there are 3 apps with 3 different rails versions
(freezed)? Will be 3 different framework handlers for each version or
less because they merge some common stuff (actually this one would be
very hard i think)?
Ok, this is the real last one, is it the same to have rails freezed or
used the one installed in the system? or does mod_rails works
differently (as performance or others)?
Thanks :)
Ok....this is really really the last :) Will your ruby branch be
available like a gem or some other ways ? (= something really fast to
install and config which would not compromise everything in the worst
case...like mod_rails :) )
Nirvana would be, seeing as you can limit it to say 4 processes per
rails app.
Say you get 16 simultaneous requests--nirvana would be that they would
all get sent to the same apache threads, so that it didn't unnecessarily
use up apache threads all waiting on rails' existing processes to
finish. Like a flood to a single rails app wouldn't distract from other
traffic.
That would be awesome! I'd be able to sleep at night knowing rails is
not hurting others on my shared host.
-R
> 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.
Is there a way to force a FrameworkSpawner to start when Apache starts?
Would you need one or multiple instances?
Is there a inactivity timeout on the FrameworkSpawner once started?
Richard