I'm reading Agile Web Development with Rails. This book is quite good. It's easy to read for non-native English speakers like me, but the content is exciting. If you're trying to use Rails, you should read this book.

But I felt sad to read these paragraphs (p.459).

Additionally, the FastCGI processes are not married to the web server process, so you can have 100 web server processes that deal with all the static requests and perhaps just 10 FastCGIs dealing with the dynamic requests. This isn't the case with servlets, CGI, and even mod_ruby (another deprecated approach to serving applications for Rails).

This is crucially important for memory consumption, as a single Apache instance will eat only about 5MB when doing static serving but can easily take 20-30MB if it needs to host the Ruby interpreter with a loaded application. Having 100 Apaches with 10 FastCGIs will use only 800MB of memory while having 100 Apaches each containing mod_ruby process can easily use 3GB of memory. RAM may be cheap, but there’s no reason to be such a spendthrift about it.

I admit that FastCGI gives a better performance than (at least current Rails support of) mod_ruby, but this comparison is not fair. Usually, mod_ruby users run another Apache instance (or light Web server like lighttpd) for static requests in such a serious situation, so there is no need to have 100 Apache processes for mod_ruby.