F still comes before S
Posted by MSch Sat, 07 Jan 2006 20:24:00 GMT
Some time ago David Felstead, a senior Site5 engineer, said that Site5 was considering switching from FastCGI to SCGI and so I decided that if Site5 was considering it, I could simply do it.
He wrote about some major pains in the proverbial with FastCGI:- It’s hard to set up
- It’s hard to monitor
- It requires dedicated tasks to keep working (reaper, spawner, spinner anyone?)
- Currently no one is actively developing the Apache module.
According to him SCGI is better, because it only took him 15 minutes to set up properly. And now for the but:
As you, dear well informed reader, of course know one feature of FastCGI is to keep multiple instances of the Rails dispatcher open. SCGI in combination with the Apache module supports exactly one instance of the dispatcher. There is one obscure and in reality impossible way of changing that but believe me you don’t want to do this.
For me monitoring seemed easier because reaper, spawner and spinner already exist for FastCGI opposed to my self-written Ruby script that tries to do the same for SCGI.
And if that wouldn’t be enough SCGI also simply delegates every request below a defined path to Rails, which of course sucks if you have static content in your application. You can try to work around that, but once you generate .js or .css files through Rails, you pretty much start hating SCGI.
But uninformed as I was, I just went ahead and let SCGI handle my requests. Till today. Today I made Rails use FastCGI. I didn’t exactly follow the instructions in that article, instead of compiling anything myself I just let apt and RubyGems do all the hard work:
sudo apt-get install libfcgi-dev
sudo gem install fcgiFor me switching from SCGI to FastCGI brought nothing but relieve: My requests seem to get handled faster (probably because of the multiple instances running concurrently) and I no longer have to breach DRY, as my .htaccess doesn’t need to exclude non all rails handled requests.
