Hey there, > 1. Ruby on Rails, with lighttpd/mongrel, a database > 2. Ruby on Rails, mod_ruby with Apache2, a database > 3. Ruby on Rails, FastCGI with Apache2, a database
I used #3 quite a little bit before figuring out that it's not optimal from the following point of view. Apache has worker threads that handle requests and serve content. When some static file is requested (css, js, html, ...) the thread is created and has a small memory footprint (some 1-5 Mb, which is huge compared to some lightweight servers, like nginx). When it's PHP / FastCGI, there has to be more memory allocated (up to 35-50 Mb in my experience). As Apache reuses workers, over the time all workers hold the maximum memory and, as you can realize, make the server choke (constant swapping etc). What I came up with was a cluster of mongrel workers per application (usually 2 is enough if you don't do anything lengthy during the request handling, which is bad by definition, or unless you have an application bombarded by requests rapidly). So mongrel + the_server is a great combination. You let the server serve the static content, and let mongrel, with almost fixed memory footprint, do the interactive job. I don't name the_server as it's possible to use several solutions in this configuration and it's completely up to you what to go along with. I prefer nginx as a front end, which proxies all requests and gives PHP to Apache, Rails to Mongrel, while serving static itself. That's pretty much all to it. - A --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Deploying Rails" group. To post to this group, send email to rubyonrails-deployment@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
