RoR and FastCGI: Scaling using processes instead of threads

Wednesday, Apr. 13 2005 | Author: Scrivs

If you have been using Ruby on Rails or at least investigating it you should have come across FastCGI at one time or another. Many Ruby developers that I have talked to swear by this method of serving Ruby since it seems to be extremely fast and less resource-dependent. CodeHaus has a good writeup describing the differences between Java’s method of threading in contrast to FastCGI’s method of processes. This tidbit is what interests me:

In contrast, a FastCGI implementation will on startup pre-fork off a number of CGI processes. Each process will listen to standard input (or any other IPC solution such as named pipes, domain sockets or even network sockets in case of a cluster). As a request comes in an available process is chosen and the content of the request is sent as name-value pairs to the process. The FastCGI implementation captures the output and sends it back to the client. The process is then returned back to the pool of available processes.

Of course that made me wonder what would happen in a server farm environment and I saw that this problem was raised in the comments.

…if you for example create one hundred FastCGI processes per server in a 20 blade cluster then each separate process needs to allocate one database connection. This would amount to 2000 database connections which occupies a lot of memory (both in the database server and on the client) and bluntly put just doesn’t scale.

It’s also interesting to note how many Java programmers are always in the defensive about their language. I figured by now that all developers would understand that programming languages are just tools to use so defending one over the other as if it is a life or death situation makes no sense to me. Most likely they are looking out for their jobs.

Share and Enjoy

A DIY Guide to Installing Ruby, Rails, and FastCGI
University of Illinois Launches 640 Xserve Turing Cluster
Open Supercomputing Turns 10
Google Desktop Proxy
PHP 5 Installer for OS X

Hope you like that post!

Forever Geek is a resource for all things geek. You can stay tuned by having the latest FG news delivered to you for free via RSS.

Category: Uncategorized
Tags:

4 Responses for "RoR and FastCGI: Scaling using processes instead of threads"

Sam Newman

April 13th, 2005 at 11:19 am
1

Quite the contrary – most of the people hyping Ruby/Ruby on rails are java programmers. That is the major problem – they are hyping. I’ve seen precious little balanced commentry on RoR. You question a pro piece, and you’re immediately jumped on for being “defensive” and “bashing”. Bottom line: even those people talking it up right now are not using it for much in the way of commercial development (that’s where you get paid in Real Cash Money, not Ego Blog Points), and you have to ask the question why. Will it ever happen? Perhaps – but we need a more mature discussion on the subject than the current blog hype.
Scrivs

April 13th, 2005 at 11:34 am
2

Good points indeed Sam. Yeah currently it seems Basecamp is carrying the flag with regards to major Ruby development and I am sure most enterprises wouldn’t consider that large-scale enough to give it a second glance.

However, I don’t see the need for Ruby to even hit the enterprises because what Rails does is open the web app game up for the little guy. Now developers can create web apps even quicker (assuming they know what they are doing) and with less effort than say with Java so I wouldn’t be surprised to see a lot of RoR popping up all over the place. Problem is many of these apps will just be rehashes of things we have already seen in PHP and Perl.
Sam Newman

April 14th, 2005 at 12:52 pm
3

I agree – for the little guy the fact that RoR gets you up and running quickly is a real plus. Interestingly, this is a similar market that much of the .NET toolset is aimed for – making stuff easy to use over offering the ultimate in scalability. I can’t see many people deciding to drop a weblogic clister in favor of RoR, but I can see people choosing RoR over ASP.NET
Matt Galaviz

April 17th, 2005 at 1:36 pm
4

One of the major reasons people would choose RoR over ASP.NET is the “free” factor. Other than that, I haven’t seen RoR hosting or may sites even using that. I’m sure in the near future it might happen, but with .net, php, jsp, cfm, RoR might have a hard pushing into the market *just my opinion*.