mod_ruby or fastcgi+ruby?

[Gully Foyle]

What are the pros & cons of mod_ruby vs fastcgi+ruby? Ruby will most
likely be the latest stable snapshot (1.8.2).

The only requirement is the server running Apache 2.x (not 1.3) on
Redhat Advanced Server 3.x (kernel 2.4.20-smp).

The site won't be high-volume but it needs to be stable/robust (for a
single server website).

I'm getting the impression mod_ruby is a lot easier to setup (super
simple apache config). I'd love to hear about any hidden gotchas with
either scenario.

Thanks.

 

[Kirk Haines]

What are the pros & cons of mod_ruby vs fastcgi+ruby? Ruby will
most likely be the latest stable snapshot (1.8.2).

mod_ruby:

+ Nice access to Apache internals.
+ Fast.
+ You can write handlers for Apache with it. Handlers can let you do
powerful things.
+ Eruby, if you like that.
+ Easy config.
- Interpreter is shared among all users of mod_ruby. Potential for namespace
clashes because of this.
- mod_ruby is an Apache specfic thing. So your code isn't portable to
other web server types.

fast_cgi:
+ A familiar, conventional CGI-like interface.
+ Fast.
+ Pretty easy to configure this, too, though there is more complexity to
fine tuning it.
+ Many web servers support FastCGI, so your code is more portable.
+ Each seperate FastCGI application is in its own process so no namespace
clashes possible between different applications.
- It IS more complex than mod_ruby.
- Don't have the same level of access to the web server internals.

It's six of one, a half dozen of the other, really. Both work well. Both
can handle busy web sites with good performance and stability. Is there a
particular templating system or web development framework that you want to
use? If so, does it support both of these, or is it better with one of
them? Which one seems more interesting to you? Can some of what you want
to do be done via a handler? Is it important to you to have your code
portable to other web server software?

The answers to those questions may well point you toward one or the other.


Kirk Haines

 

[Carl Youngblood]

Neither is very hard to set up in a run-of-the-mill unix environment.

 

[Gully Foyle]

On Wed, 21 Jul 2004 23:47:03 +0900, Gully Foyle wrote



mod_ruby:

+ Nice access to Apache internals.
+ Fast.
+ You can write handlers for Apache with it. Handlers can let you do
powerful things.
+ Eruby, if you like that.
+ Easy config.
- Interpreter is shared among all users of mod_ruby. Potential for namespace
clashes because of this.
- mod_ruby is an Apache specfic thing. So your code isn't portable to
other web server types.

fast_cgi:
+ A familiar, conventional CGI-like interface.
+ Fast.
+ Pretty easy to configure this, too, though there is more complexity to
fine tuning it.
+ Many web servers support FastCGI, so your code is more portable.
+ Each seperate FastCGI application is in its own process so no namespace
clashes possible between different applications.
- It IS more complex than mod_ruby.
- Don't have the same level of access to the web server internals.

It's six of one, a half dozen of the other, really. Both work well. Both
can handle busy web sites with good performance and stability. Is there a
particular templating system or web development framework that you want to
use? If so, does it support both of these, or is it better with one of
them? Which one seems more interesting to you? Can some of what you want
to do be done via a handler? Is it important to you to have your code
portable to other web server software?

The answers to those questions may well point you toward one or the other.


Kirk Haines

Thanks for the great info! It was very helpful.

I think the only remaining question I have is regarding this:

- Interpreter is shared among all users of mod_ruby. Potential for
namespace clashes because of this.

I'm not quite sure I understand the nature of the namespace clash in
mod_ruby.

When I tried to set a global counter variable just to see what happens,
it appears that each instance of apache process gets its own copy. And I
was under the impression (I could be totally wrong) that only one
request is served up by each process at a time.

Thanks again for the info you've already provided.

 

[Kirk Haines]

- Interpreter is shared among all users of mod_ruby. Potential

for > namespace clashes because of this.

I'm not quite sure I understand the nature of the namespace clash in
mod_ruby.[/QUOTE]

Each seperate Apache process has its own interpreter. However, each of the
different users of mod_ruby within a process share that same interpreter.

So doing something has a global effect in one piece of code can affect the
execution of an unrelated piece of code later.

Since it sounds like you are in control of your own server, this probably
isn't an issue to worry too much about. Just don't use globals much, or if
you do. make sure you are careful with the names, don't modify base classes
in a way in one piece of code that will break another, and generally respect
each piece of code's stomping ground, and you'll be fine.


Kirk Haines

 

[David Garamond]

fast_cgi:
- It IS more complex than mod_ruby.

Depends on the definition of "complex". I myself see fastcgi as far less
complex than Apache+mod_ruby (e.g. compare the number of lines of the
code). Plus if you use FastCGI, you don't have to understand Apache API
(which can be said to be "complex" too). You only have to understand the
CGI protocol, which is understood by perhaps 95-99% of web programmers.

Anoher + for fastcgi: it's easier to use it in a shared hosting
environment. Since I provide shared hosting, I currently don't provide
mod_perl/mod_php/mod_ruby. PHP runs as a CGI script (with a special
module), and all CGI scripts are wrapped to each user's UID. And fastcgi
is supported since it's easy to wrap the fcgi scripts using the
FastcgiSuexec mechanism.

 

[Kirk Haines]

fast_cgi:
- It IS more complex than mod_ruby.

Depends on the definition of "complex". I myself see fastcgi as far
less complex than Apache+mod_ruby (e.g. compare the number of lines
of the code). Plus if you use FastCGI, you don't have to understand
Apache API
(which can be said to be "complex" too). You only have to understand
the CGI protocol, which is understood by perhaps 95-99% of web programmers.[/QUOTE]

I think the use of complex here refers to the overall setup and config.
Neither is very complex, but there are more knobs that can be turned with
FastCGI in the setup.

Anoher + for fastcgi: it's easier to use it in a shared hosting
environment. Since I provide shared hosting, I currently don't
provide mod_perl/mod_php/mod_ruby. PHP runs as a CGI script (with a
special module), and all CGI scripts are wrapped to each user's UID.
And fastcgi is supported since it's easy to wrap the fcgi scripts
using the FastcgiSuexec mechanism.

Definitely. The options when providing shared hosting are to just not worry
about it and hope there are no problems, or to not provide mod_(language)
support. No argument there.


Kirk Haines

 

[David Morton]

When I tried to set a global counter variable just to see what happens,
it appears that each instance of apache process gets its own copy. And I
was under the impression (I could be totally wrong) that only one
request is served up by each process at a time.

That's true, as each apache instance gets its own interpreter. To keep
track of a counter, use some persistant storage, or, my favorite, ruby::Asp

Couldn't a mod_ruby/eruby/asp environment take care of namespace clashes
by somehow putting scripts in different applications? As far as I know,
I haven't had any such clashes when using perl Apache::Asp.

 

[Kirk Haines]

On Fri, 23 Jul 2004 00:52:19 +0900, David Morton wrote

Couldn't a mod_ruby/eruby/asp environment take care of namespace
clashes by somehow putting scripts in different applications? As far
as I know, I haven't had any such clashes when using perl Apache::Asp.

There are three issues. First, namespaces don't protect you if another
piece of code changes the behavior of Array. This is one issue that Perl
doesn't have because you can't change the behavior of an array like you can
in Ruby.

Second, namespaces don't help your code and some other code use the same
global variable.

And third, namespaces don't help you if someone else's code intentionally
mucks around in your namespace.

In practice, so long as one takes a little care with coding, it is rarely a
problem. In theory, though, especially in a shared hosting environment, it
could be ugly.


Kirk Haines