hello,
i’m currently using nginx as proxy for webrick running redmine. i’m
not very happy with this, i would like to run redmine using fastcgi
with nginx (without proxying to webrick, mongrel, etc.). however, as
i’m new to nginx and not very familiar with ruby/rails, i could need
some help.
this is my script for spawning the dispatch.fcgi from redmine:
#!/bin/bash
exec 2>&1
export RAILS_ENV=production
export LANG=en_US.UTF-8
exec /usr/local/bin/spawn-fcgi -p 9001 -u www-data -g www-data -f
/usr/local/redmine/public/dispatch.fcgi
however … i don’t have a clue how to configure nginx fastCGI for
redmine/ruby/rails for this spawned process. i’ve tried different
things, but all result in a “500 – internal server error”.
any help is very appreciated!
regards,
harald
On Tue, Apr 28, 2009 at 3:12 PM, Harald L. [email protected]
wrote:
#!/bin/bash
things, but all result in a “500 – internal server error”.
any help is very appreciated!
regards,
harald
config please?
why are you avoiding mongrel - the performance is much better than
webrick and it’s pretty easy to manage (using mongrel_cluster)?
Or if you are more adventurous try the new mod_rails for nginx. My tests
show it to be stable and fast, and though my production sites use
mongrel, it is sure easier to manage mod_rails.
Guy.
On Tue, Apr 28, 2009 at 10:36 PM, Guy N. [email protected] wrote:
Or if you are more adventurous try the new mod_rails for nginx. My tests
show it to be stable and fast, and though my production sites use mongrel,
it is sure easier to manage mod_rails.
Guy.
can you please enlighten me on this one?
how exactly is this easier? I’ve read several information on this but
still don’t get why this method is better.
Hi,
I didn’t say it’s better - it’s EASIER. The reason it’s easier is that
the mod_rails module is the one that actually manages the backend. That
means two major things:
- You don’t need to use mongrel_cluster or a FastCGI launcher
- When the app die for some reason, the module will handle the
relaunching for you. This eliminate the need for something like monit or
a fastcgi spawner process.
There are also some other advantages like memory usage if you use Ruby
Enterprise Edition, but that’s a different story. It does comes with a
global queue support (similar to what the EY balancer does).
Bye,
Guy.
Hi,
Edho P Arief wrote:
for you. This eliminate the need for something like monit or a fastcgi
spawner process.
so basically it’s like php-fpm? (and mongrel_cluster is spawn-fgi/php)
It’s similar, but the difference is, it’s based not on checking
processes and such, but actually managing child processes of the
spawner. When using FastCGI with Rails (I used to do that with lighttpd)
we had the spinner and spawner scripts that checked on the running
processes and relaunched them if they were dead. But mod_rails actually
launches and kills workers based on timeouts and request logs… It’s
smarter in the way it works, and using the global queue option you can
get better predictability with apps having long requests.
But I still use mongrels in production, launching and controlling them
with monit. I still need to test more on the working of mod_rails to
know for sure it’ll meet my production requirements. That’s why I said
it’s EASIER but didn’t say it’s better.
Bye,
Guy.
On Wed, Apr 29, 2009 at 12:41 AM, Guy N. [email protected] wrote:
so basically it’s like php-fpm? (and mongrel_cluster is spawn-fgi/php)