Not to sound like I’m bashing Rails, I’ve been using it since early 2005, and have deployed dozens upon dozens of apps with Rails, but the deployment of Rails is really a problem. I’ve supported my self virtually entirely from writing Rails code since late 2005. I’m a big fan.

I don’t think JRuby is ultimately the answer. I hope Rubinius is, but even then someone needs to find a universal way to deploy Rails apps, by dropping a .rba (or whatever) into a directory and having everything “just work”.

Someone needs to step up and rewrite mod_ruby or write a mod_mongrel, or most companies will start deploying to J2EE containers.

I’m not sure why you think that multiple Mongrel processes won’t help. If you find that your server’s responsiveness is still jammed, just increase the number of Mongrel processes. If you find that your server can’t handle that number of processes, then you have too many visitors.

PHP doesn’t solve it. In fact, PHP really isn’t much different. By default, Apache allocates up to 150 or so request handlers, which can run concurrently. Each request handler can run exactly one PHP script at a time (i.e. process one HTTP request at a time). The PHP script is run inside the Apache process. If you configure Apache to only use 1 request handler, and your PHP script jams for 10 seconds, then your web server will be unresponsive.
Mongrel_cluster is similar. The number of concurrent requests that your clusters can handle is proportional to the number of Mongrel processes in the cluster.

So the difference with PHP is that PHP uses Apache’s number of request handlers, and thus doesn’t require any additional configuration. Mongrel_cluster requires you to manually set the number of processes in the cluster.

That’s good, but multiple Mongrel’s does not save you from long running processes jamming your responsiveness. Which is what Ikai was hinting at with background image processing.

Out of interest, how does PHP solve this issue? I’d be surprised if it had an automatic queue for long running processes… which is the exact issue…. and even if it did, it would not be ‘painless’ since it would require some level of work to set up

The difference there is that your Rails app is massively popular, and your PHP one is just used by your grandma.

In addition, you can setup Lighttpd to serve static files directly, instead of letting them go through Mongrel. This is an example of a stock Lighttpd snippet that I use:

NO_PROXY_EXTENSIONS = "\.(png|gif|jpg|css|js|iso|exe|wmv|mpg|avi|rar|zip)$"
...
} else $HTTP["host"] =~ "(^|\.)kennissysteem\.com$" {
        $HTTP["host"] == "beta.kennissysteem.com" {
                server.document-root = "/home/webapps/kennissysteem/systeem/public"
                $HTTP["url"] !~ NO_PROXY_EXTENSIONS {
                        proxy.server = ("" => (
                                ("host" => "127.0.0.1", "port" => 3865),
                                ("host" => "127.0.0.1", "port" => 3866)
                        ))
                }
                accesslog.filename = "/home/webapps/kennissysteem/systeem/log/lighttpd.log"
        } else $HTTP["host"] =~ "" {
                url.redirect = ( "^/(.*)" => "http://beta.kennissysteem.com/$1" )
                accesslog.filename = "/dev/null"
        }

Here you see beta.kennissysteem.com powered by 2 Mongrel instances. Whenever I deploy a new site, I copy & paste this snippet and change a few values.

I have experience with Ferret and acts_as_ferret. In fact my current project uses it. I run the Ferret server. I agree that it’s less than ideal, but why is it a problem? I only had to run one command - it’s fire-and-forget.
The underlying problem is that Ferret stores the index of the filesystem. If there’s a PHP indexing engine that also use the filesystem, I’m pretty sure it would run into similar issues.

I really do not understand why you talk about “risk”. All this stuff seems fairly simple to me.
- How do you count risk?
- It seems like you’re counting “risk” by the number of manual steps. Is that really an accurate way to count risk? Let us take, for example PHP. The number of effective PHP instances is equal to the number of concurrent Apache request handlers. This is setup in your Apache config file. Now suppose that PHP one day decides to force you to enter this number manually, in a seperate configuration option. And that you have to start these PHP instances manually, instead of letting Apache start them automatically for you. This will be just like how mongrel_cluster works. Will PHP’s risk have increased?
- Why do you think JRuby will reduce risk? Is it only because it uses Java, which you already know, or are there other reasons as well?

But in the end, it all comes down to the threading issue, which, because of the way a Mongrel Rails stack is architectured, introduces risk. There is virtually no risk in deploying a PHP application; the upload either completed, or didn’t complete. Maybe painful is not the best description. “High risk” is probably a better term. This is part of the reason I’m looking so closely at JRuby - in theory, Glassfish could solve all these problems.

Given the lack of support by hosting providers its certainly does make this experience _painful_

But once you know how and are using the proper tools for deployment, it couldn’t be easier.