Gregg,
Due to Rails not being thread safe, you will end having at least a
couple of Mongrel processes to handle a bunch on simultaneous incoming
requests. Even if you can start with just one Mongrel instance, having
the cluster setup is a good policy.
You could also take a look a Thin (I supports clusters out of the
box), or Ebb (look damn fast)as replacements for Mongrel (I have tried
Thin and it is doing great) also you could try God instead of Monit,
it provides a behavior to clean stale pid files, so you could go back
to single Mongrel instance without the cluster support if you decide
so.
http://code.macournoyer.com/thin/
http://ebb.rubyforge.org/
http://god.rubyforge.org/
You are lucky to have Ezra's book, before that, there were only
his blog posts to show some light in the darkness of Rails
deployment ;-)
--
Aníbal Rojas
http://hasmanydevelopers.com
http://rubycorner.com
http://anibal.rojas.com
On Mar 6, 7:55 pm, Greg Willits <[EMAIL PROTECTED]>
wrote:
> I've been reading through the book "Deploying Rails Applications,"
> studing a setup done by someone els, and creating my own new setup.
>
> In the end it appears that mongrel_cluster (deemed "required" by these
> setups) actually has no purpose in my final setup.
>
> Looking for validation or a counter opinion.
>
> In each case the deployment ends up with the OS launching monit at
> startup (launchd on OS X Server in my case), and monit with a repetitive
> config block that launches one instance of mongrel/rails.
>
> In the book, they use mongrel_cluster, but each "cluster" is just one
> mongrel. In the live example I have to look at, they just stuck with
> mongrel_rails to launch each one.
>
> Now, the book goes through these stages of showing how to launch one
> mongrel, then mongrel_cluster, then mongrel_cluster_ctl, and finally
> monit -- which just takes us right back to essentially launching one
> mongrel at a time again.
>
> I've been creating my own new setup, and I went with mongrel_rails per
> monit config block like this:
>
> start program =
> "/usr/bin/mongrel_rails start -d
> -e production -p 8100
> -a system.local -t 30
> -P /MY/RAILS/ROOT/log/mongrel.8100.pid
> -c /MY/RAILS/ROOT"
>
> After having done all that, I'm left wondering what the whole point of
> mongrel_cluster is. I now have a mongrel_cluster and mongrel_cluster_ctl
> config setup that appears to be useless now that I have monit
> controlling them.
>
> So, is the book just showing various techniques as exercises (doesn't
> read that way)? Perhaps one would choose not to use monit? but then how
> control these leaky beggers?
>
> Seems to me there was no need to even install mongrel_cluster, and at
> this point I may as well rip it out and eliminate the extra work of
> installing and configuring it. Which in my case means a clean install of
> OS X Server has everything I need right out of the box except for monit
> (which a quick compile solved that).
>
> Am I missing something?
>
> -- gw
> --
> Posted viahttp://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Deploying Rails" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-deployment?hl=en
-~----------~----~----~----~------~----~------~--~---
