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 2009-04-28 12:21
on 2009-04-28 19:09
On Tue, Apr 28, 2009 at 3:12 PM, Harald L. <email@example.com> 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)?
on 2009-04-28 19:45
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 2009-04-28 21:33
On Tue, Apr 28, 2009 at 10:36 PM, Guy N. <firstname.lastname@example.org> 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.
on 2009-04-28 21:47
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: 1. You don't need to use mongrel_cluster or a FastCGI launcher 2. 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.
on 2009-04-29 10:27
On Wed, Apr 29, 2009 at 12:41 AM, Guy N. <email@example.com> wrote: > so basically it's like php-fpm? (and mongrel_cluster is spawn-fgi/php)
on 2009-04-29 20:02
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.