edit

S is the new F - Let the age of SCGI Rails begin...

Posted by David Felstead Fri, 23 Sep 2005 10:43:00 GMT

Ruby on Rails is a great framework, but to get any kinds of usable performance out of it, it needs to be run as a persistent application. Out of the box (or gem), Rails apps on Apache run as CGI applications – this means that for every request sent to your Rails app, Apache will go through the process of loading the entire framework, executing your request, and shutting it back down again. This, as you can imagine, is horrendously inefficient.

Up until recently, the only way to get Rails hosted with any decent amount of speed was to use FastCGI, or FCGI. FastCGI differs from regular CGI in that a number of persistent processes run on the webserver, and requests are farmed off to them as they are received. What this gets us is a big performance boost – the framework only needs to load once (for each worker process), and can serve requests with very low overhead. There are some very high traffic sites running with Rails on FastCGI, so it is a viable solution. But is it a good solution for Rails? Well… no.

The theory behind FCGI is fine – no worries there – it’s the implementation that’s a problem. FCGI with Ruby on Rails:

• Is a royal pain in the proverbial to set up;
• Is very difficult to monitor;
• Requires scheduled tasks/cron jobs to clean up after itself – ph33r the reaper (not to mention the spawner and the spinner)
• ...and is not currently under active development (the base library, anyways).

So… what to do? Well, enter Zed Shaw, SCGI, and his SCGI Rails Runner (or SRR for short) script. SCGI is FCGI done nicely – it’s the same concept, but with a significantly less complex implementation – that’s gotta be a big plus for anyone. The SRR, along with mod_scgi in Apache and lighttpd delivers the same performance as FastCGI, with a pure Ruby implementation – this is pretty impressive and a credit to Zed as a coder – FCGI uses compiled native code, yet SRR, a mere interpreted piece of Ruby script can keep pace with it. Impressive.

My experiences installing SRR with Apache2, once I had some instructions were very good – now bear in mind I’ve dicked around with FastCGI for hours, and still had little success, but from installation of mod_scgi and copying of the scgi_rails script to being up and running was less than fifteen minutes. Nice. Very nice.

There are aspects of configuring Apache that still need looking at in my configuration; the most notable of them is the fact that all web requests, bar those with a ’.’ in the filename are routed through SCGI - I’d like to make sure that only Rails stuff is routed through there, ala the dispatch.fcgi method in FastCGI. No doubt this can be achieved with some mod_rewrite funkiness, but my knowledge of it’s inner workings is somewhat limited. However, this is a minor thing and probably makes little difference to the overall performance – I’m just pig-headed and like things working my way. :)

SRR is still very young, but the fact that it is already at a usable level is unbelievably impressive, and to me highlights the promise in the project. I have no doubt that SCGI and Zed’s SRR will dethrone FastCGI on Rails very shortly…

Given its obvious advantages, we’re strongly considering offering it alongside RoR with FastCGI here at Site5 for all your Ruby on Rails web hosting needs – from there, the choice is yours. Let us know if you’re interested!